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ABSTRACT 



End user computing has penetrated most large organiza- 
tions in an uncontrolled fashion. The newness of the tech- 
nology, the lack of management expertise, and the inability 
to gain corporatewide control under the traditional organi- 
zational structure have often resulted in inefficiency, 
incompatibility, and missed opportunities. One solution to 
this situation is the Information Center (IC). ICs are 
centralized coordination centers for end user computing and 
offer end user computing expertise. ICs may be any combina- 
tion of consulting services, training services, mainframe 
computer terminals, or microcomputers. This thesis examines 
the IC concept from the viewpoint of the manager tasked with 
implementation and provides a methodology, the Systems 
Development Life Cycle, to evaluate and implement an IC. 

Each phase of the methodology is explained and some innova- 
tive ideas on IC implementation and operation are provided. 
Examples of past successes and mistakes are also presented. 
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I, 



INTRODUCTION 



A. INFORMATION CENTER DEFINED 

The concept of the Information Center (IC) was formal- 
ized by International Business Machines (IBM) Canada in 1974 
[Ref. 1: p. 73]. IBM defines the IC as "a portion of the 
Information Systems development resource organized and dedi- 
cated to support the users of Information Systems services 
in activities such as report generation and modification, 
data manipulation and analysis, spontaneous inquiries, etc." 
[Ref. 2: p. 131] Other corporations have used, changed, 
renamed, refined, and redefined the IC concept to fit their 
own purposes. Although this flexibility may appear to be 
counterproductive, it seems to be one reason for the popu- 
larity of ICs . 

Many corporations have adopted the name Information 
Center. Some of the other documented names for ICs include 
Information Resource Center [Ref. 3: p. 27], Client Support 
Center [Ref. 4: p. 137], User Support Group [Ref. 5: p. 16], 
Resource Center [Ref. 6: p. 19], User Development Applica- 
tion Center [Ref. 7: p. 65], Solution Center [Ref. 8: 
p. 30], and Office Technology Center [Ref. 9: p. 71]. 

The term Information Center has also been used to desig- 
nate other manual or automated services such as library 
services, abstract and document retrieval services, and 
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central repositories for documents. Although valid, these 
services represent an entirely different concept and are not 
a consideration of this research. 

The IBM definition of the IC focuses on the use of a 

mainframe computer. This narrow focus does not adequately 

define the IC concept used by many corporations. Therefore, 

the following three definitions are provided: 

The Information Center is not a place; it is a concept 
which combines technology and the technical expertise of 
the MIS department of the organization with the business 
skills of those in other areas in the organization to 
better leverage both the power of information processing 
technology and the organization's data. [Ref. 10: p. 42] 

. . .an IC is an organization whose objective is to provide 
the tools and support that allow end users to deal direct- 
ly with some subset of their MIS needs. As such, the IC 
facilitates end-user computing, providing tools rather 
than solutions. [Ref. 11: p. 16] 

An information center consists of a facility and resources 
which can allow users to carry out their own data process- 
ing according to their immediate needs. [Ref. 12: p. 63] 



B. PURPOSE 

The purpose of this research is to develop a method or 
guide for managers to evaluate and implement the IC concept. 
Therefore, the perspective of this thesis is from that of 
the manager tasked with the responsibility for evaluation 
and implementation of the IC. This person is often from the 
data processing or management information systems depart- 
ment. The methodology used is the systems development life 
cycle (SDLC) . Selection of this method was based on the 
idea that an IC can be thought of as a large project or 



system. Managers need a framework within which they can 
develop the IC concept and SDLC provides one of the sim- 
plest, most complete, and adaptable methods available. 
Recently, SDLC has gained great popularity within the infor- 
mation industry in the design of computer information sys- 
tems. Another reason to use SDLC is that managers who used 
SDLC before will be able to more easily evaluate and imple- 
ment ICs . 

C. DESCRIPTION 

Descriptions of ICs are varied and plentiful. One at- 
tempt to provide a standard description of ICs is the 
following ; 

The centers (ICs) may differ in the services and facili- 
ties they offer... But information centers all have the 
fast, convenient characteristics of the hot line, and they 
all endeavor to empower users. [Ref. 13: p. 98] 

ICs are more commonly found in large corporations, but 
are rapidly migrating to smaller ones as the popularity of 
the IC concept increases. Most IC implementations include a 
physical facility with a manager, an administrative assist- 
ant or secretary, and one or more people designated to 
conduct training and consultation. Although other positions 
and functions can be found in the various ICs, this descrip- 
tion is fairly generic. The physical layout usually in- 
cludes some sort of terminal or mix of terminals. The 
quantity and arrangement of terminals will depend on the 
purpose of the facility. In physical terms, the IC may be 



used as a site for training, for daily user access, for user 
or corporate hardware and software evaluation, or for hard- 
ware and software selection. ICs frequently include a com- 
bination of more than one of these purposes. 

ICs can be partitioned and labeled in several different 
ways. For purposes of description they are easily classi- 
fied as follows: 

1 . Host-Connected 

2. Stand-Alone 

3. Networked 

4. Mixed 

A Host-Connected classification means that the IC is 
composed of terminals (some of which may be microcomputers 
used as terminals) connected to the host computer, usually a 
mainframe computer. All work is done through the use of the 
host computer. A good example of this type is installed at 
Anheuser-Busch where "It is virtually impossible for employ- 
ees to buy a microcomputer." [Ref. 14: p. 13] 

A Stand-Alone classification involves the use of one 
machine by one individual to process information. This is 
usually a microcomputer. This type of IC frequently in- 
volves provision of some type of purchase service, mainte- 
nance service, introductory training, coordination for 
compatibility, setup (including software installation), 
instruction on equipment care and use, and the opportunity 



to sample and evaluate different machines (usually with 
strong orientation toward microcomputers and software). 

A Network classification may involve outside timesharing 
services. Coordination and proper use of these services are 
emphasized. Another type of Network classification involves 
local area networks (LANs) that are not connected to host 
computers but are established to fulfill a need to maximize 
local communications. 

The most common classification is the Mixed classifica- 
tion. It is also the most advanced implementation of the 
IC. It is a combination of any two or all three of the 
other classifications. The range of sophistication in the 
mixed classification is broad. At the low end, the micro- 
mainframe connection involves the transfer of data files 
which can be used by the software and operating systems of 
either the microcomputer or the mainframe. At the high end, 
all three of the other classifications can be implemented in 
an integrated fashion. 

Some implementations will be difficult to categorize in 
this manner. For example, implementations which are purely 
conceptual, trivially simple, or based on distributed appli- 
cations may be hard to assign to any of these categories. 
Nevertheless, these implementations will favor one of the 
four classifications listed above and can be categorized 
with one of these four. 



It is important to acknowledge the present state-of-the- 

art in information technology in order to have some idea of 

where the IC concept is heading. F. Warren McFarlan and 

James L. McKenney, Harvard University ,■ have written about 

the concept of phased merging of different technologies. 

Their position is as follows: 

Organizationally, there are multiple paths which can be 
followed in effecting the merger of the three islands 
(Data Processing, Telecommunications, and Office Automa- 
tion) of technologies as a firm moves toward a merged 
information services function. [Ref. 15: p. 34] 

The multiple paths they make reference to are the following: 
1 . Merging Data Processing and Telecommunications 
2- Merging Telecommunications and Office Automation 
3. Merging Data Processing and Office Automation 
In this context the three singular IC classifications of 
Host-Connected, Stand-Alone, and Networks can be compared 
with Data Processing, Office Automation, and Telecommunica- 
tions, respectively. The state-of-the-art for implementing 
these paths exists today. On the other hand, complete 
integration of the three paths does not exist. Although the 
information processing industry has been working toward this 
goal, only limited integration has been achieved. 

Although McFarlan and McKenney are not addressing ICs in 
particular but rather information technology as a whole, 
their logic can be extended to IC organization and technolo- 
gy. They summarize their thoughts with the following; 



...at present a wide array of organization patterns are 
possible as an organization advances toward the totality 
of information services. We see this heterogeneity as 
transitional, with the eventual merger of these islands 
into a central hub occurring in most organizations; cer- 
tainly for policy making, planning, and control purposes, 
and in many settings, for line control and execution. The 
timing of these moves in any organization is situation de- 
pendent, involving current corporation structure and lead- 
ership style, speed at which the firm has been staying 
modern in these technologies, individual retirement plans, 
current development priorities, and so forth. [Ref. 16: 
p. 36] 



II . SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY 



A. BACKGROUND 

The SDLC, applied to an IC, is a combination of the 
systems approach and the life cycle approach. The systems 
approach causes one to view the IC as a system which con- 
tains its own subsystems and at the same time is part of a 
larger system. The life cycle approach considers the fact 
that the IC is created, is developed, grows, matures, and 
either expands into something else or becomes obsolete. 
Although one can not always predict the future, especially 
concerning a concept as new as the IC, there are certain 
aspects that can be predicted which can contribute to a 
better IC. 

This thesis views the systems approach much the same way 
as Kenneth Boulding did in 1956, as summarized by James 
Wetherbe in 1984: 

The systems approach is the way of thinking about the job 
of managing. It provides a framework for visualizing 
internal and external environmental factors as an inte- 
grated whole. It allows recognition of the function of 
subsystems, as well as the complex suprasystems within 
which organizations must operate. Systems concepts foster 
a way of thinking which, on the one hand, helps the manag- 
er to recognize the nature of complex problems and thereby 
to operate within the perceived environment. It is impor- 
tant to recognize the integrated nature of specific sys- 
tems, including the fact that each system has both inputs 
and outputs and can be viewed as a self-contained unit. 

But it is also important to recognize that business sys- 
tems are a part of larger systems--possibly industrywide, 
or including several, maybe many, companies and/or 



industries, or even society as a whole. Further, business 
systems are in a constant state of change--they are 
created, operated, revised, and often eliminated. 

[Ref. 17: pp. 32-33] 

The value and flavor of the systems approach are described 

by the following: 

The systems approach is a perspective--a way of identi- 
fying and viewing complex, interrelated functions as inte- 
gral elements of systems. Although there is concern for 
the individual parts of a system, emphasis is on the 
integration of the components to produce the end products 
of the systems themselves .... Systems analysis provides a 
set of strategies and techniques for dealing with complex 
problems, based on hierarchical partitioning methods ap- 
plied through various levels of abstraction to analyze 
problems and synthesize solutions ... .A basic principle of 
systems project management is that the systems development 
life cycle should be a guide, not a cookbook .... systems 
analysis is a process that involves repeating, or iter- 
ating, a series of process steps to build an understanding 
of current systems and procedures and to define new sys- 
tems. [Ref. 18: pp. 14, 22, 72, 167] 



B. EXAMPLE 

The best way to explain, in this thesis, how the SDLC is 
applied to ICs is to provide a facetious but pedagogic ex- 
ample. Consider the example of a person standing outside in 
the cold in a strong breeze. He starts out by saying he has 
a problem: he is cold. This is what an untrained person 
says. But a trained person, similar to a systems analyst, 
would say that being cold is the symptom and that the real 
problem is that he needs shelter. Therefore, the problem is 
now well defined. 

The next step is to determine the requirements. The 
untrained person says he needs to buy a house. The analyst 



instead reviews the shelter requirements. For example, a 
house may not be needed in the tropics or there may be other 
options like a trailer home or renting. The analyst deter- 
mines that a dwelling is needed and because there are other 
system requirements (e.g., standard of living, social sta- 
tus, family size, weather, cost, etc.) the analyst starts 
describing a system that generally fits the requirements. 

The next step is to determine details, such as number of 
toilets and amount of insulation required. At this point 
the analyst realizes that this person's car must also be 
protected and that it should be part of the shelter system. 
The analyst goes as far back as necessary to re-analyze the 
system. The analyst determines that a garage or carport 
would do nicely. When integrated with the original require- 
ment the analyst realizes that the garage or carport must be 
attached to the house in order to provide shelter for the 
person when walking from the car to the house. After re- 
viewing requirements and creating several designs or op- 
tions, the analyst considers all factors such as cost, 
amount of shelter and other uses and chooses the proper 
house and car storage system. 

Since this is a life cycle study, things such as long- 
term maintenance, property appreciation, and expected life 
were evaluated based on the overall objectives of the person 
needing the shelter. The choice is made based on the 



foregoing and the house is built and cared for in the manner 
previously planned. 

Although this example is simplistic, it does explain the 
procedure and general thought process that makes the SDLC a 
valuable methodology and useful in the development of an IC. 
Iteration, going back to the beginning or as far as neces- 
sary, and hierarchical decomposition, "the breaking down, or 
partitioning, of a large problem, or project, into a series 
of structured, related, manageable parts" [Ref. 19: p. 52] 
were demonstrated in the example. At each major decision 
point in the example, the feasibility of continuing the 
design as it had been developed up to that point had to be 
determined . 

C. PHASES AND ACTIVITIES 

Figures 1 and 2 are partially modified versions taken 
from a book by Michael J. Powers, David R. Adams, and Harlan 

D. Mills [Ref. 20: pp. 42, 50]. Figure 1 presents the 
phases and activities of the SDLC utilized in this study. 

"A phase is a set of activities that brings a project to a 
critical milestone ... .An activity is a group of logically 
related tasks that, when completed, lead to accomplishment 
of a specific objective." [Ref. 21: pp. 50-51] Figure 2 
indicates checkpoints where a conscious decision whether to 
proceed, delay, speed up, postpone, or abandon should be 



made . 



INVESTIGATION PHASE 
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2. Feasibility Study 
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Existing System Review 
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New System Requirements 
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New System Design 
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Detailed Design and Testing Plann 



DETAILED 


DESIGN AND TESTING PHASE 
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Technical Design 
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Performance Specification and 
Measurement Planning 
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Staffing 
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Prototyping and System Testing 
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General Implementation Planning 



INSTALLATION AND IMPLEMENTATION PHASE 


13. 


Marketing 
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Training 
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Hardware 


17. 


Software 


1 8. 


Managing and Controlling 
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Opportunities 



REVIEW PHASE 

20. Development Recapitulation 

21 . Post Implementation Review 



Figure 1 . SDLC Phases and Activities 



20 



INVESTIGATION 



<DECI 

5 


SIOl^ 


ANALYSIS AND 
GENERAL DESIGN 


5 


\ 

SIOI^ 

r 


DETAILED DESIGN 
AND TESTING 


<sDECI; 


SION^ 

r 


INSTALLATION AND 
IMPLEMENTATION 




1 


REVIEW 



Figure 2. Major Decision Points 
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Each chapter following this chapter, with the exception 
of the conclusion chapter, deals with one of the phases of 
the SDLC. Since these chapters contain explanations of the 
purpose and objectives of each phase, only a broad overview 
will be provided in this chapter. Five phases have been 
used in this study. Figure 1 provides a breakdown of the 
activities of each phase. These activities have in some 
cases been modified to reflect considerations peculiar to an 
IC. The purpose of the investigation phase is to define the 
problem, identify requirements, and determine general feasi- 
bility of one or more solutions. The purpose of the analy- 
sis and general design phase is to develop a more detailed 
analysis, create a general design for an IC, and reconfirm 
feasibility based on the additional information acquired. 

The purpose of the detailed design and testing phase is to 
reduce the general design to a detailed design, to test the 
system (usually with a prototype), to examine feasibility 
one last time, and make any last minute changes. The pur- 
pose of the installation and implementation phase is to 
convert from the old system to the new IC system as pain- 
lessly and professionally as possible. The purpose of the 
last phase, the review phase, is to immediately evaluate the 
methodology and at a later time to review and evaluate the 
operation and success of the IC in meeting its objectives. 
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D. CONTROL 



Figure 2 shows the major decision points as diamonds and 
the phases as boxes. These decision points indicate feasi- 
bility reviews and are only made after each of the first 
three phases. The decision to proceed should be made by a 
top level manager or a high level steering committee. On 
the other hand, the SDLC study should be conducted, if at 
all possible, by a team of people: 

If the project proposal is approved, management generally 
organizes a project team and assigns responsibility for 
the project to it. The specific personnel or type of 
personnel to be included on the project team should be 
defined under the resource requirements section of the 
project proposal. [Ref. 22: p. 123] 

The organization of a project team is a prerequisite to 
good systems analysis. Different types of expertise are 
required to thoroughly consider all system variables. For 
example, the systems analyst provides primarily computer 
technology-oriented skills. Without adequate represen- 
tation from the various departments affected by the in- 
formation system, various dimensions of their needs and 
requirements are apt to be overlooked. [Ref. 23: p. 123] 

Figure 3 is a partially modified version of a figure 

developed by James C. Wetherbe [Ref. 24: p. 11]. The main 

concept of Figure 3 is that of iteration and hierarchical 

decomposition. As the SDLC study starts at the top of 

Figure 3 it progresses to the bottom, through each phase, 

until some new development causes a return to an earlier 

phase or to the beginning. This is shown by the direction 

of the arrows. This concept is explained by Wetherbe: 

The steps in the cycle (SDLC) are neither discrete nor 
one-time processes. Rather, the systems development cycle 
is iterative and evolutionary. The steps in the cycle. 
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Figure 3, Iteration and Hierarchical Decomposition Process 
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however, retain a basic sequential flow from the point of 
origin of the development cycle--" new problems and/or 
opportunities arise . " At any step in the cycle, previ- 
ously unidentified problems and/or opportunities may be 
discovered. In such cases, it is important to insure 
proper integration of a solution to a new problem and/or a 
new opportunity. Making even a minor change to a system 
without proper consideration of what has been established 
previously, can cause unanticipated and undesirable rip- 
pling effects. [Ref. 25: p. 11] 



E. GENERAL COMMENTS 

Some final words on the SDLC contain both advice and 
caution: 

The systems approach is a problem oriented one. It is a 
highly creative process, and the outcome is dependent upon 
the people involved as well as on the resources avail- 
able .... Moreover , in any given situation, the available 
data and theoretical framework are likely to be incomplete 
and somewhat ambiguous so that certainty is out of the 
question. Imagination, judgement and courage are needed. 
The set of possible future environments in which proposed 
solutions must remain valid have to be imagined, and their 
potential effects evaluated. Alternative solutions must 
be generated, characterized and evaluated. Even the way 
the problem domain under study is subdivided for concep- 
tual manageability is a matter of considerable importance 
that demands responsible judgement and originality. The 
traditional subdivisions along jurisdictional or organiza- 
tional lines, or in terms of standard academic disci- 
plines, are not necessarily the best and are certainly not 
the only options. Each aspect has its place and must be 
considered. Clearly, creativity is called for at many 
points in the process of achieving a problem solution. 

[Ref. 26: p. 9] 

A vast, complex system has many elements with significant 
interactions that are often not understood. Isolating the 
elements for analysis may lead the systems analyst to 
overlook the interactions that occur when the elements are 
combined into a system.... In particular, a system that 
involves human behavior (e.g., an organization) involves 
varying and changing variables that interact with, and/or 
compromise, the system. One of the key realizations con- 
tributed by the systems approach is that the interactions 
among elements in a system can be as, or more, important 
than the elements themselves. A system is more than just 
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the sum of its parts and must be considered as such. [Ref 
27: pp. 33-34] 

Although the process of systems analysis is straightfor- 
ward in concept, it can be exceedingly complex and diffi- 
cult in application. It must be emphasized that systems 
analysis is not a panacea. It is not a black box into 
which one drops problems at one end and automatically 
receives solutions at the other. It is, as was pointed 
out, a framework in which a multi-disciplinary group of 
scientists, engineers and technicians can achieve a uni- 
fied problem-oriented focus, and this common research 
orientation maximizes the possibilities for achieving 
successful solutions of complex problems. The real value 
of systems analysis lies in the fact that it forces a 
manager to structure his thinking to the problem at hand, 
to prepare a solution given a particular set of circum- 
stances, to prepare alternatives and to establish require 
ments . [Ref. 28: p. 12] 
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III. INVESTIGATION PHASE 



A. PURPOSE OF INVESTIGATION PHASE 

The chief purpose of the investigation phase is to deter- 
mine whether a problem or need requires a full systems 
development effort or whether another course of action is 
appropriate. One alternative course of action may be to 
do nothing, to leave operations as they are. Another 
alternative may be to undertake a project to upgrade, or 
maintain, the existing system rather than to develop a new 
one. [Ref. 29: p. 44] 

During this phase, the problem is defined, needs are 
identified, and possible solutions are presented. This 
phase has two parts. The first part is the initial investi- 
gation. The second part is the feasibility study. Determi- 
nation of the need to conduct a feasibility study is the 
result of the first part. At the conclusion of the investi- 
gation phase which is also the conclusion of the second 
part, a decision must be made whether or not to proceed with 
the next phase of the SDLC. 

B. INITIAL INVESTIGATION 

1 . Source Identification 

The source of the request or order to implement an 
IC or to initiate an SDLC, may come from any department or 
individual within the corporation or organization. It is 
important to identify this party early, preferably at this 
point in the SDLC. Knowing this party's identity can assist 
in the determination of the initial support groups and 
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possible behavioral problems. If this party is top manage- 
ment, then one can expect high level support and can plan 
accordingly. If not, then a different outlook will be 
required. If this party is a group, then it is valuable to 
know who the proponents are or at least the ratio of propo- 
nents to opponents. If an IC is established under the 
misconception that the entire group supports the idea when, 
in fact, they do not, the consequences may be disastrous. 
Identification of this group or individual will also help to 
identify some of the political issues that may have an 
impact on the IC decision. Early identification of the 
behavioral aspects and of the source of the IC request will 
more than likely have a profound impact on the determination 
of the approach to be taken and the problem to be solved. 
Current literature stresses the sensitivity of ICs to var- 
ious factions of resistance, political infighting, and the 
necessity of top-management support. 

2 . Motivation 

It is important to understand this party's motiva- 
tion. There will usually be more than one reason for want- 
ing to implement an IC. Among the various reasons for 
implementing the IC, two are mentioned more than others. 

One is to reduce the applications backlog and the other is 
to control the proliferation of microcomputers. Some addi- 
tional reasons are to coordinate technological growth, to 
provide end user training, to provide data security and 
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integrity, to give users control of their own data, to 
provide consultation to end users, to administer end user 
computing, to reduce the effect of system analyst and pro- 
grammer shortages, to provide a test bed for new hardware 
and software products, to reduce the load on the host com- 
puter, to improve data processing department's relations 
with user departments, and to provide a central point for 
end user standards. 

In addition to the advertised reasons for implement- 
ing an IC, it is vital to uncover hidden motivations, as 
well. A very common hidden motivation is internal empire 
building or managerial territorial conflicts. Another hid- 
den motivation is the need or desire to match or even sur- 
pass a competitor's position. This may be nothing more than 
a race to be the first to install the latest technology or, 
if the competition cannot be equalized, it may cause the 
corporation to fail. Another hidden motivation is to effect 
an organizational change. This is often done to accommodate 
personalities or poor individual performance. Usually, the 
implementation of the IC has little effect on sustained 
performance and rarely does it solve personality problems. 
The impact of not correcting these situations prior to 
taking any action can be devastating to the success of the 
IC. Finally, there may be other hidden motivations and 
these should also be identified and corrective action taken 
if necessary. 
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3. The Envisioned Information Center 



The interested party may already have their own idea 
of what will constitute the IC. Although this may be less 
than optimal, it is important to record and thoroughly 
understand this party's idea. At this point in the SDLC, 
there should be no attempt to change their position. It may 
turn out that their intuition or analysis is accurate and 
that any conflict now, may encourage future conflict, unnec- 
essarily. Likewise, it is likely that this party will view 
the IC as a one time implementation when in actuality it 
should be viewed as an evolutionary process [Ref. 30: 
pp. 211-212]. Therefore, this party's view will probably 
change as the SDLC study progresses. 

4 . Research on the Information Center Concept 

It is virtually impossible to address the issue of 
an IC unless one understands the IC concept. Therefore, it 
is necessary to learn as much about ICs as possible. At a 
minimum there should be a literature search. This can be 
started at the local library or university. This research 
can be extended to include the hiring of a consultant to 
give a presentation on the IC concept. Attending workshops 
or seminars can also be rewarding, as well as discussions 
with others who have already implemented an IC. Visits to 
IC sites should be arranged if possible. Vendors can pro- 
vide a different view. It may also be feasible to join a 
local users group. IC users groups and special interest 
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groups have been gaining popularity and it is not difficult 
to find one in almost any section of the United States 
[Refs. 31: p. 26, 32: p. 26, 33: p. 12]. It may also 
be useful to join certain computer related professional 
associations. Lastly, any opportunity not already mentioned 
should be considered. Properly conducted research on the 
nature of ICs and learning from the successes and failures 
of other groups can save a considerable amount of time and 
money . 

5 . Problem Definition 

At this point in the study, the problem to be ad- 
dressed should be formally stated or defined. This can be 
somewhat difficult because of the foregoing and because it 
is often difficult to separate symptoms from causes. It 
will involve determination of general business objectives, 
information system objectives, and user needs. This is not 
the place to espouse solutions. It is quite possible that 
the problem may require something different than an IC. 

a. Goals, Strategy, and Competitive Position 

Alignment of the problem to business objectives 
is critical to proper perspective. Corporate goals, strate- 
gy, and competitive position will be a strong guide in 
determining areas that should be exploited. It will also be 
a large determinant of the economical justification of the 
solution. For example, if the corporate goal is to capture 
seventy percent of the market, then alternate goals such as 
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maximizing profit will be secondary considerations. If top 
management will not disclose the corporation's goals (possi- 
bly due to security concerns) or has not performed any long- 
term strategic planning, then it is recommended that goals 
should be established based on the best available informa- 
tion. [Ref. 34: p. 11] Competitive position is determined 
by the success of the corporation's strategy. McFarlan 
gives a synopsis of each of Michael E. Porter's three cate- 
gories of competitive strategies as follows: 

• 

One (strategy) is cost based, when a company can produce 
at a much lower cost than its competition. Companies 
selling commodities and high-technology products can use 
such strategies. A second type is based on product dif- 
ferentiation, when a company offers a different mix of 
product features such as service and quality. (Companies 
selling baby care products and cosmetics can use this 
strategy.) The third type is specialization in only one 
niche of a market, distinguishing itself by unusual cost 
or product features. Its strategies may be called fo- 
cused. (An example would be focusing on a narrow range of 
industrial grade papers to avoid advertising battles.) 
[Ref. 35: p. 100] 

Porter identifies these three strategies as "generic strate- 
gic approaches" [Ref. 36: p. 35] and labels them as follows: 

1 . overall cost leadership 

2. differentiation 

3. focus 

It is important to understand which strategy is being 
used by the corporation so that the solution will maximize 
the corporation's competitive position. Additionally, 
awareness of the competitive position, such as knowing the 
market share or profit differentials of the industry, can 
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assist in development of areas that will create more return 
on the investment. If the solution supports this position, 
then it will provide the opportunity to exploit the competi- 
tion's weaknesses and to capitalize on the corporation's 
strengths . 

b. Information System Strategy 

Understanding the corporate strategy and goals 

is only part of the overall picture. The IC must also fit 
into the information systems strategy. The data processing 
workloads, emphasis areas, and future plans should be con- 
sidered. The IC should complement the data processing, 
telecommunication, and office automation efforts unless 
obsolescence, economy reasons, or some other valid reason 
make this undesirable. 

c. Management Structure 

Understanding the management structure can help 
to identify the users. A common method to describe a corpo- 
ration's management structure is depicted by a pyramid seg- 
regating the three levels of management: top management, 
middle management, and operational management. This idea is 
carried one step further by Dan Trimmer [Ref. 37: p. 43] 
where in Figure 4 he shows the trend of data processing 
support for each level. Figure 4 shows a shift toward more 
data processing services for top and middle management. 

This trend points to the growth rate of these classes of 
users and in general the need to solve their problems and 
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Data Processing (DP) The percentages show how DP 

Services - Present is addressing the different 

levels of management. 




Data Processing (DP) The percentages show how DP 

Services - Future will address the different 

levels of management. 




Figure 4. Data Processing Trends 
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fulfill their data processing needs. It also emphasizes the 
future importance of ICs since they mainly support top and 
middle management. This concept can help provide an esti- 
mate of the number of users. 

d. User Needs Analysis 

All information needs should be identified. 

This may seem like extraneous work, but in the end it will 
save time and will help to coordinate and integrate the 
requirements of diverse groups within the organization or 
corporation. This avoids duplication, provides a universal 
picture of the organization's needs, provides a vehicle for 
a more complete analysis, and provides a more accurate 
format for needs prioritization. It is important to concen- 
trate on scope rather than level of abstraction or amount of 
detail. The latter is dependent on corporation size, auto- 
mation maturity, and other considerations. Once these needs 
have been determined, the current methods for meeting these 
needs must be identified. In some cases these methods will 
be manual; in other cases they will automated. It is quite 
possible that they will not have been addressed at all or 
have been addressed in a deficient manner. Determination of 
needs is difficult to do well because of the high degree of 
subjectivity and a requirement to be creative. Neverthe- 
less, extra time spent in this activity will reduce the 
number of corrections and facilitate revisions during the 
SDLC. 
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Although each implementation of the IC concept 
is different, user needs can be categorized in general 
terms. These needs are segregated into system types by 
Robert M. Alloway and Judith A. Quillard in Figure 5 
[Ref. 38: p. 30]. The types of requirements commonly served 
by ICs are listed in Figure 5 under the categories of in- 
quiry and analysis under the managerial support systems. 

The transaction processing system supports the lowest level 
of the previously mentioned managerial pyramid, the opera- 
tional level which is generally not supported by an IC . 

C. FEASIBILITY STUDY 
1 . Purpose 

The purpose of the feasibility study is to determine 
whether the new system (IC) should be developed, to develop 
alternative solutions, to recommend the best solution, and 
to provide a projected budget for the new system. It is a 
determination of whether a project is possible, practical, 
and realistic. The feasibility study is a miniature systems 
analysis study that builds on the results of the initial 
investigation. It covers essentially the same ground as the 
analysis and general design phase, but in far less depth. 
[Ref. 39: pp. 120-145] 
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producing standard reports on a fixed 
schedule (daily, weekly, or monthly). 



Exception The system processes detail activity reports 
where the definition of exception conditions 
is fixed. 



Inquiry The system provides a database with flexible 
inquiry capability, enabling managers to 
design and change their own monitoring and 
exception reports. 

Analysis The system provides powerful data analysis 
capabilities (modeling, simulation, 
optimization or statistical routines) and 
the appropriate database to support 
managerial decision-making. 



Figure 5. Description of Systems Types 
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2 . 



Alternative' Solutions 



Since the initial investigation has been completed 
and the problem has been defined, solutions are now consid- 
ered. Among the possibilities are the following: 

a. Do nothing - Maintain the status quo. 

b. Expa nd the existing system - Add more resources of the 
same type (people, equipment, software). 

c. Contract-out - Pay for outside services. 

d. Reorganize existing services - Decentralization is the 
most common occurrence. 

e. Establish new policies - Often used to control micro 
proliferation. 

f. Instal 1 an IC - This is the most that can possibly be 
done in terms of a new system, under this study. 

3 . The New System 

The needs analysis conducted in the initial investi- 
gation is the source for this part of the SDLC. By now, a 
general idea of what the IC will entail should be formu- 
lated. The type of IC (ie. Host-Connected, Stand-Alone, 
Networked, or Mixed), should be identified. A rough idea of 
the size and contents of a physical site and the number of 
staff personnel should be decided. Approximate figures for 
number of users, IC usage rates, supply requirements, organ- 
izational location, costs, and benefits should be developed. 
The following categories of feasibility [Ref. 40: p. 122] 
should be addressed: 

a. Financial feasibility 

b. Operational feasibility 
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c. Technical feasibility 

d. Schedule feasibility 

e. Human factors feasibility 

In determining overall feasibility, the old system must be 
considered. James C. Wetherbe , writes the following on this 
issue: 

In the excitement of implementing new technology, it is 
often easy to overlook certain capabilities or function- 
alities of the old technology and to leave them out of the 
new system. Such actions result in disillusionment with 
the new system and nostalgia for the the old system. 
Therefore, it is critical to conduct a thorough analysis 
of the old system before final design decisions are made 
on a new system. [Ref. 41: p. 128] 

In terms of the IC, this means that the data processing 

department resources, host and microcomputer usage, software 

support, and manual procedures of the existing system are 

reviewed and considered. 

4 . Proi ected Budget 

Part of the feasibility study is comprised of a 
cost/benefit analysis. This analysis provides input to the 
development of the projected budget. The projected budget 
should combine costs and time and result in financial mile- 
stones and a schedule of expenditure of funds. It is better 
for upper management and for future performance evaluation 
measurements, if a cost justification for the IC is 
developed . 
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D. RECOMMENDATION 



The final requirement of the investigation phase is to 
make a general recommendation. This thesis assumes that the 
development of an IC is required and that it is the best 
solution. The recommendation should include a general de- 
scription of the intended IC. A projected budget and a 
justification should accompany this description. The next 
phase of the SDLC requires a closer investigation of the IC 
solution . 
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IV. ANALYSIS AND GENERAL DESIGN PHASE 



A. PURPOSE OF ANALYSIS AND GENERAL DESIGN PHASE 

The purpose of the analysis and general design phase is 
to develop a more detailed understanding of the existing 
system, to establish a general design of the new system, to 
secure management and user approval, and to develop a plan 
for the next phase, detailed design and testing [Ref. 42: 
p. 238]. The analysis and general design phase consists of 
a review of the existing system and development of new 
system requirements, new system design, and a plan for 
detailed design and testing. Formation of the IC staff 
should begin during this phase so that staff personnel may 
assist with the SDLC study, help guide the IC's development, 
and to plan for their new roles. The IC staff should be 
advised, however, that it is possible that they will be 
required to return to their former positions should approval 
for implementation be denied. 

B. EXISTING SYSTEM REVIEW 

The purpose for reviewing the existing system is to 
build an understanding of the business goals, objectives, 
and functions involved in the application areas encompassed 
by the project. Emphasis is on development of a logical 
view of these areas of understanding. Although the physical 
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view can be of assistance in arriving at the logical view, 
it should not be confused with the logical view, even though 
the logical-physical boundaries may not be well defined. 
Also, neither view should be substituted for the other. 

The existing system review should be a more detailed 
review of the analysis already conducted. This review 
should entail a review of available data, organizational 
climate, organizational placement of information systems, 
work station (terminal or microcomputer) employment and 
deployment, user and management satisfaction, existing poli- 
cies and their effect, information constraints, existing 
information system strengths and weaknesses, report genera- 
tion, existing technological capabilities (e.g. graphics, 
electronic mail, networks, fourth generation software, 
etc.), the degree of acceptance of information technology, 
the growth position of the corporation or organization, the 
personnel situation (competency, morale, interest, etc.), 
and any other aspect or item that could be of assistance in 
determination of the logical view of the existing informa- 
tion system. 

This information is highly situation dependent and will 
vary greatly from one organization or corporation to anoth- 
er. One concept that does not seem to change in this envi- 
ronment is the experience of the organization or corporation 
in the assimilation of new technology. There has been 
considerable discussion and writing on the stages of 
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assimilation of technology. These stages have broad appli- 
cation to most organizations or corporations regardless of 
other differences. The stage hypothesis also explains some 
of the anomalies observed in the orderly growth of computer 
technology. In an article in EDP Analyzer [Ref. 43: p. 6], 
the following synopsis succinctly addresses this issue: 

Nolan's and Gibson's landmark 1974 paper [Ref. 44: 
pp. 76-88] observed that many organizations go through 
four stages in the introduction and assimilation of new 
technology. These are: Introduction, proliferation, con- 
trol, and mature usage. During the proliferation stage, 
the idea catches on and spreads 'like wild fire,' until 
costs clearly get out of hand. In the third stage, con- 
trol is exercised in order to contain the growth of costs. 
Finally, mature usage occurs in the fourth stage. An 
organization can be in several stages simultaneously, for 
different forms of technology. 

McKenney and McFarlan [Refs. 45: pp . 109-119, 46: 
pp. 145-156, 47: pp. 36-40, 70-73] discuss a somewhat 
modified version of the four stages (or 'phases,' as these 
authors prefer). Their four phases are: (1) identifica- 

tion and initial investment, (2) experimentation and 
learning, (3) management control, and (4) widespread tech- 
nology transfer. This version of the four phases has the 
advantage, we believe, of casting the important second 
phase in a somewhat different light from Nolan and Gibson. 
Nolan and Gibson gave a negative name--proliferation--to 
this phrase, leaving the impression that users are being 
almost irresponsible by adopting the new technology too 
rapidly. McKenney and McFarlan point out that this is the 
stage when experimenting and learning take place--a trial 
and error phase. If too much control is exerted too soon, 
important new uses of the technology can be killed off. 
[Ref. 48: p. 6] 

The concept of phased assimilation of technology is not only 
useful in understanding the existing system, but will also 
be a consideration in other segments of the SDLC. 

Understanding the user and technology is only part of 
the work involved with reviewing the existing system. The 
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other part involves understanding top management's goals and 
objectives and how these goals and objectives fit into the 
existing structure. This often requires not only observa- 
tion and interviews, but a keen ability to sort out super- 
fluous and misleading information. System analysts and 
outside consultants can provide unbiased and unaffected 
analytical ability for this endeavor. 

C. NEW SYSTEM REQUIREMENTS 

The purpose of this activity is to develop a description 
and statement of the new system requirements in sufficient 
depth for user evaluation and approval. This usually 
results in the development of a user requirements specifica- 
tion. This document contains requirements that are satis- 
factory to the user and approved by the user. It also is 
common practice to establish priorities within this document 
because either development costs may make it impossible to 
implement every request or phased implementation may be 
recommended . 

Development of systems requirements is a difficult task 
because the IC concept is relatively new, the technology in 
support of the IC is rapidly developing, the requirements 
are dependent on the situation which can be radically dif- 
ferent from all other situations, and the approach to be 
taken in this endeavor is unclear and often untried. As a 
starting point, reexamination of Figure 5 can help to 
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determine what the IC can offer, before deciding what it 
should offer. The six options listed under managerial sup- 
port systems in Figure 5 provide an excellent list of possi- 
ble user requirements. Each one of these options, when 
used, should be tied to a specific function and one or more 
databases. The users of each of these combinations should 
also be identified. These groupings can be viewed as a 
requirements matrix of options, databases, and users. Any 
of the elements of this matrix may be repeated in the forma- 
tion of these groupings. 

A slightly different approach categorizes requirements 
by application size and development time. Figure 6 provides 
a list of these categories in relation to the overall view 
of information systems. The last three items in Figure 6 
describe appropriate uses of an IC and provide a different 
perspective for developing IC requirements. 

USER WAIT 

PATH AVERAGE QUEUE 



Traditional Life Cycle (TLC) 

Prototyping 

Purchase Software 

Small Systems Implementation (IC) 

Ad Hoc Requests (IC) 

Consulting for End-User Computing (IC) 



1 - 2+ years 
6-1 8 months 

2- 6 months 
1 -2 months 
1 -2 days 

1 -2 hours 



Figure 6. Alternate Service Paths [Ref. 49: p. 103] 
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It may be helpful to combine the perspectives of both Fig- 
ures 5 and 6 . 

The requirements specification should tell the user what 
requirements the IC will satisfy. These requirements are 
not stated in physical terms but rather in the logical terms 
mentioned earlier. An example of a physical requirement is 
to provide a terminal or microcomputer to every person in 
the accounting division. An example of a logical require- 
ment is to provide all supervisors in the accounting divi- 
sion query access to the general ledger database for report 
generation and statistical analysis. Because IC technology 
is new, gaining popularity, and easy to relate to, the 
tendency is to want to rush to a decision and select equip- 
ment and software before the requirements are defined. This 
should be avoided. 

The uniqueness of the IC, as compared to other systems 
development projects, requires that service requirements 
also be identified. Determination of the need for the IC to 
provide these services should be reviewed. Considerations 
may be training, consulting, programming support, applica- 
tion systems development, hardware and software procurement 
and testing, equipment maintenance, configuration control of 
hardware and software, vendor interfacing, obtaining group 
discounts, assistance in user cost/benefit analyses and 
justification studies, product demonstrations, newsletter 
publishings, supporting user groups, network control and 
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assistance, database interfacing, data extract services, 
security, data integrity, backup and recovery services, 
installation and setup of hardware and software, provision 
and availability of manuals and documentation, consumable 
supplies (e.g. printer paper and ribbons, diskettes, disk- 
ette holders, labels, etc.), procurement of computer furni- 
ture, timesharing services, electronic mail coordination, 
office automation control and implementation, providing hot 
line services, applications libraries, standards and compat- 
ibility management, marketing services, site licenses for 
software, microcomputer loan services, mainframe performance 
monitoring, planning assistance, and anything else that may 
be appropriate. Because of the different user responses to 
services, the requirements for some of these services may be 
indeterminable until actual installation and usage has oc- 
curred. The level and quantity of services may also be 
difficult to estimate before their provision. 

D. NEW SYSTEM DESIGN 

The purpose of new system design is to provide suffi- 
cient information to serve as a basis for a decision on 
whether to continue with implementation. The feasibility 
analysis is updated, and user and management commitment and 
approval are secured. The life cycle structure precludes 
full technical design during this activity, partly because 
this level of commitment has neither been made nor funded. 
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This activity results in a new systems design specification 
and an updated feasibility study. The latter includes prep- 
aration of accurate estimates for all five dimensions of 
f easibility--f inancial , technical, operational, scheduling, 
and human factors. Controls are also considered to assure 
accuracy, completeness, reliability, and quality of results 
produced. [Ref. 50: pp. 457-487] 

The separation of general design from detailed design is 
often unclear. One guide to determine what to consider 
under general design is to determine if a more detailed 
level exists beyond the one under consideration. Another 
guide is to determine if further detail is necessary to more 
accurately determine feasibility in order to make a decision 
on IC implementation. Regardless of how one ascertains the 
level of detail, the question of how to proceed still ex- 
ists. There is no single methodology for this process. 

One way to proceed is to start with an overall review of 
the requirements. Since the requirements should have been 
developed with the business goals and objectives in mind, it 
seems logical to review these goals and objectives again. 

The IC goals and objectives should also be examined. Some 
examples of reasonable goals are to: 

1. maximize end user productivity; 

2. reduce the application backlog pressure; 

3. control the proliferation of microcomputers; 

4. educate the user about data -processing; 
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5. to improve the relationship between data processing 
and the user; 

6. reduce the amount of data and increase the amount 
of information; 

7. encourage an entrepreneurial attitude towards users; 

8. restructure the data processing organization; or, 

9. for any other acceptable reason. 

The user requirements are then matched to design re- 
quirements, For example, if a spreadsheet analysis capabil- 
ity is required, then the general design should determine 
the number and location of immediate or potential users, the 
type and amount of data to be accessed, the data access 
requirements, the requirements for integration with other 
software, the location of the data, and the sophistication 
required of the spreadsheet software. This should then 
result in a general design that supports either mainframe or 
micro implementation using either an integrated or stand- 
alone software package that should or should not be 
networked to other systems. Choosing the exact type of 
spreadsheet software would not be appropriate for this level 
of design and should be determined during detailed design. 

This example illustrates the interrelationships of some 
of the various facets of the general design problem and 
gives some indication of the complexity involved and the 
vast number of options available. It is important to try to 
satisfy the important user requirements first. This 
priority should be based on corporate goals and objectives. 
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There will most likely be some design tradeoffs and deci- 
sions that must be made. These decisions are more effec- 
tively made at this design stage rather than at the detailed 
design stage where mistakes are more costly. 

The result of this activity is a general design specifi- 
cation and a more accurate and detailed feasibility study. 
These documents form the basis for management, user, and IC 
implementation personnel approval. 

E. DETAILED DESIGN AND TESTING PLANNING 

The purpose of this activity is to establish a prelimi- 
nary plan for the next phase, the detailed design and test- 
ing phase, and to recommend a general approach for testing 
the newly designed IC. This plan should provide a general 
guideline to determine which areas require further detail 
and to determine the level of detail required. This plan 
should also provide a general overview of the testing activ- 
ity and should result in establishment of general acceptance 
standards and the framework for the type of testing to be 
conducted. One objective of this plan is to eliminate as 
many surprises as possible during development in order to 
eliminate surprises after development. Another objective of 
this plan is to ensure that major items are not overlooked. 

There are two areas of consideration for the detailed 
design and testing plan. The first area concerns the 
identification of the items which require additional detail. 
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The level of detail will depend on the requirements of the 
problem, the size of the planned IC, the amount of risk 
involved, and the experience of the development team. The 
second area concerns the method to be used to test the new 
design. In most IC implementations a prototype, a pilot 
study, or a similar test vehicle should be utilized. This 
allows experimentation under controlled conditions. It also 
reduces end user frustration when the IC begins to operate, 
because operational problems should have surfaced and should 
have been eliminated during the testing phase. This plan 
should make transition from design to testing easier. 



51 



V. DETAILED DESIGN AND TESTING PHASE 



A. PURPOSE OF DETAILED DESIGN AND TESTING PHASE 

The purpose of the detailed design and testing phase is 
to turn specifications into a developed ready-to-use system 
that is completely documented, fully tested, and approved by 
users and management. This phase involves technical design, 
performance specification and measurement planning, staff- 
ing, prototyping and system testing, and general implementa- 
tion planning. 

B. TECHNICAL DESIGN 

The purpose of the technical design activity is to 
expand the general design of the previous phase to a deeper, 
more detailed level. This activity results in a design 
specification that is as complete and detailed as possible. 
Technical design identifies the actual hardware and 
software, the physical layout, services to be offered, com- 
munications architecture, database configuration, adminis- 
tration, controls, and management structure. Technical 
design can be thought of as answering detailed "what" ques- 
tions. The "how" questions are reserved for the next phase, 
installation and implementation. 

One of the easiest technical design tasks is the identi- 
fication of the actual hardware and software. Vendors are 
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usually very accommodating in providing information. Most 
of the larger vendors are also willing to 'let organizations 
and corporations use both hardware and software on a trial 
basis. In most cases it is fairly easy to survey current 
users of these products to determine their level of satis- 
faction. These users can provide information on vendor 
performance and response and on the benefits and drawbacks 
of the product they are using. 

The detailed physical layout should, at a minimum, in- 
clude blueprints of the floor layout. These blueprints 
should address not only furniture placement, but also power 
requirements, lighting, work flow, noise levels, ergonomic 
factors, safety, security, and comfort. Current literature 
stresses a separate training facility for classroom type 
training, location of consultants in close proximity to each 
other to enhance intra-staff communication, adequate noise 
control around work stations, provision of adequate space 
for administration requirements (i.e. supplies storage, 
equipment processing and repair, etc.), and a work station 
for each staff member. The location of the IC has a lot to 
do with the layout considerations and should also be deter- 
mined during this phase of the SDLC. N. Dean Meyer, a 
consultant in advanced automation, writes the following 
about the location of the IC: 

The physical location of the information center is another 
critical management issue. It can be located within the 
offices of the information staff or placed in an area 
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occupied by end users. Space in the information staff's 
offices is usually easier to acquire than space in end- 
user quarters; however, that makes the center less acces- 
sible to users, requiring greater initiative on their 
part. [Ref. 51: p. 19] 

The services that the IC will provide should be identi- 
fied in the detailed design specification. The administra- 
tion of these services should be a function of the next 
phase, the installation and implementation phase. The fol- 
lowing list contains some of the services often provided by 
ICs : 

1 . training in the utilization of hardware and software 

2. consultation on hardware and software problems 

3. equipment maintenance, repair, and acquisition 

4. vendor interface (group discounts) 

5. software and hardware configuration control 

6. loan out of hardware and software 

7. newsletter publication 

8. software, documentation, and publications library 

9. users group coordination 

10. product demonstrations (hardware and software) 

1 1 . database extracts 

12. clearinghouse for all data processing requests 
Design of the communications architecture mainly con- 
cerns outlining the various connections and methods of con- 
nection between devices. This would include network design, 
time share service, micro-mainframe interfaces, and office 



54 



automation design. The placement of protocol converters and 
the type of protocol conversion would also be included. 

Technical design also involves the database configura- 
tion. Conversion of files to databases, combining and sepa- 
rating of databases, design of user access, location of 
databases (both in a hardware and software sense), creation 
of database extracts, data integrity, and data security are 
all detailed design considerations. 

Administration, controls, and management are dependent 
on the situation. These three categories contain miscella- 
neous items not already included. For these reasons, items 
in the three categories are more obscure and sometimes 
difficult to place between this phase and the next phase. 

C. PERFORMANCE SPECIFICATION AND MEASUREMENT PLANNING 

Quite often the IC is required to prove its profitabil- 
ity. This can only be accomplished if there is some measure 
of performance and return on investment. Therefore, it will 
be necessary to determine what items are to be measured and 
to gather baseline data before the IC is implemented. If 
the performance standard and baseline measurement have not 
already been established, they should be established at this 
point in the SDLC study. This also helps to identify any 
additional design characteristics which may have been over- 
looked or misunderstood. 
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In many cases' there is no requirement for the IC to 
justify its existence. It, seems that many ICs have shown 
such astronomical returns on investment that upper manage- 
ment is not even interested in cost/benefit studies or proof 
of success . Most of these types of ICs have concentrated on 
the use of microcomputers. The following testimonials con- 
firm this situation: 

Even after only two years, Signode's (Signode Industries) 
information center has had no trouble continuing to justi- 
fy its existence to upper management. "We give presenta- 
tions to management explaining what we are and what we're 
trying to do," he (John Nylen, IC supervisor) says, "then 
we bring in end users to tell what they've done. Just 
from that, management can see that, while it's often very 
difficult to figure hard dollar savings on this type of 
program, it is so successful and so completely integrated 
into our business that we can't do without it," he says. 
"People need the information they can get with our tools 
to malce the decisions necessary to run their portion of 
the business. We are no longer expendable." [Ref. 52: 
p. 27] 

"I haven't had to justify the information center budget, 
amazingly enough," John Lucas ( IC manager for Dennison 
Manufacturing Company) said. "I'm prepared to do it. The 
return is so obvious that they (management) haven't felt 
it necessary." [Ref. 53: p.73] 

A sampling of IC applications supports the argument that a 
solid business case exists for their implementation. At 
one company, ad hoc applications showed a productivity 
improvement factor--def ined as the effort without the IC 
compared to that with the IC--ranging from threefold to 
more than a hundredfold. At the same time, return rates 
of repetitive applications ranged from 50 to several thou- 
sand percent. For some of these applications, a one-time 
use of an application more than paid for its development. 
[Ref . 54: pp. 1 8-1 9 ] 

"When we do a cost justification for a micro installation, 
we always look for a payback of not more than three 
years," (Karen) White (IC supervisor for California State 
Automobile Association) says, "but some of our paybacks 
have been more like two to three months 1" [Ref. 55: p. 60] 



56 



Although the above quotations illustrate the bright side of 
IC justification, there is a dark side as well. Managers 
will sometimes be faced with expenses that were not expected 
or were larger than estimated. The following quotations 
explain: 

The hidden costs of using personal computers don't really 
involve unknown, inexplicable processes or gadgets either. 
Most every hidden cost is a rather mundane and predictable 
necessity. . . .For large corporations hidden personal com- 
puting costs could be a six-figure tab for rewiring and 
construction work or another big bill for the cost of 
replacing obsolete computers with newer, more practical 
systems. [Ref. 56: pp. 122-123] 

To facilitate installation of the Wangnet cable throughout 
the New York Exchange's buildings, (Jerry) Burden (manager 
of office automation systems for the New York Stock 
Exchange) eventually had to spend more than $500,000. 

"The component cable of Wangnet only cost about $20,000," 
he says. "The rest of the money went to architects, 
construction workers and contractors. Every time we 
wanted to put in cable, we had to rip up parts of the 
building and draw up new plans and pay for new construc- 
tion." [Ref. 57: p. 127] 

In the first year of operation, a personal computer pur- 
chased for about $2500 may run up thousands of dollars in 
additional costs, suggests Richard Dalton, the president 
of Keep/Track Systems, a San Francisco computer consulting 
firm.... "The actual costs of operating a computer is 
frightening for people who expected their spending to end 
after their initial purchase," Dalton says. "Sometimes 
people can't believe they spent $10,000 for a computer in 
the first year. These costs are pretty damned insidious. 
They creep up on you without notice." [Ref. 58: p. 123] 

Sneider, who is an accountant (for Laventhal and Horwath) , 
not a data-processing expert, points out that the purchase 
price of an individual computer isn't great in and of it- 
self, but add a number of them together and you've got a 
significant investment. Thus allocation and efficient use 
are becoming important. [Ref. 59: p. 73] 

Most organizations will use established standard per- 
formance measurements which can be employed as is or with 
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minor mrodif i cat ions . The difference with ICs is that many 
corporations or organizations find themselves operating in 
stage two of technology assimilation. If controls are in- 
stituted during this stage, then interest is stifled and end 
user computing will most likely stall. This concept is 
treated well in the following quotation: 

Since it (end user computing) is a relatively new area, 
past practices may not meet the needs. A key point seems 
to be: Recognize that phase two in end user computing is 

a period of experimentation and learning, and is not the 
time to be exerting tight controls. The basic decision of 
whether (and how much) to encourage versus constrain end 
user computing clearly should be made by executive manage- 
ment, and this decision will affect the plans on how to 
support end user computing. Hopefully, executive manage- 
ment will come to appreciate the nuances of the issues 
involved. [Ref. 60: p. 12] 

A solution used by some organizations is to treat end user 
computing like a research and development project where 
temporary losses are accepted because the end result may be 
high yield on investment. 

D. STAFFING 

Staffing is one of the most critical issues for the 
success of the IC concept. Although some staff positions 
will have been filled already, consideration of the other 
staff positions is necessary. At a minimum there should be 
an IC manager. The IC manager should be tasked with respon- 
sibilities commensurate with the design of the IC. Usually, 
he has overall responsibility. John Seymour, president of 
Information Center Sciences, Incorporated (a consulting 
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firm) writes the following about the IC manager's responsi- 
bilities : 

The manager of this function (the IC) has got to under- 
stand the scope of the problems, the financial and system 
impacts of the marriage of two worlds. He or she has to 
see where controls are necessary and where they stifle 
objectives. While apparently serving the needs of per- 
sonal computer users, the manager must be in touch with 
the large-scale issues: communications, data access, se- 
curity, support, and much more. [Ref. 61: p. 31 ] 

If the IC is designed as a profit center, this authority may 
be quite extensive. On the other hand, if the IC manager 
gets strong guidance from a steering committee then his 
decision making authority will be minimal. Use of a steer- 
ing committee as a controlling force should be considered 
during this phase. The makeup of that committee should also 
be determined. One type of committee composition puts the 
users in charge. The following is an example of such an 
installation: 

"At Gulf (Research and Development Corporation), the [in- 
formation center] is split between the central staff and 
respective user areas," Sam Defazio noted. "Through a 
steering committee, the beneficiaries of the technology 
really 'own' the information center while Systems Develop- 
ment provides day-to-day operations," he said. [Ref. 62: 
p. 1 31 ] 

Steering committees may be chaired by top management, some- 
one from the data processing department, someone from the 
management information department, user personnel, the IC 
manager, or other IC staff members. Major decision authori- 
ty should also be decided and delineated before implementa- 
tion. Other IC positions may include trainer, consultant, 
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systems analyst, secretary, administrative assistant, pub- 
lisher, and purchasing agent. Quite often staff members 
will be tasked with the responsibilities of two or more of 
these positions as indicated in the following quotation: 

Each member of the CSC team ( IC staff), including the 
leader, or coordinator, supports one or more tools and 
provides backup in others. The secretary also gets in- 
volved by teaching word processing and answering technical 
questions about several of the tools. [Ref. 63: 138] 

The selection and recruitment of personnel, however, is a 

function of the next phase. 

The IC staff must interface with all types of people 

with varying degrees of interest and varying abilities. A 

common theme throughout the current literature is that the 

staff members need to have training and consulting skills 

more than they do computer skills. The idea is that it is 

easier to train a skilled teacher about computers than it is 

to train a computer expert about teaching and customer 

rapport. The design of ICs must reflect not only this fact 

but the following fact as well: 

Needless to say, qualified candidates for the CSC team ( IC 
staff) are scarce. Because of their excellent qualifica- 
tions and the diverse experience gained from being part of 
the CSC team { IC staff), these people are highly marketa- 
ble to other organizations. Consequently, the CSC (IC) 
has seen extensive staff turnover. Four people from the 
team have moved on to other assignments in less than two 
years. Consider the impact of a 75% or 100% turnover in a 
high performance team and how to manage for it. [Ref. 64: 
p. 140] 

One concept that may help the situation described above 
is that of providing a career path for IC staff. While some 
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publications claim that the IC is a dead-end position, 
others claim it is an excellent place to get exposure to 
other people in the organization and can be a stepping stone 
to a better position in the corporation or organization. 

That notwithstanding, Daniel Couger, a professor of computer 
management at the University of Colorado College of 
Business, has outlined a career path for computer pro- 
fessionals that shows how the IC staff can progress in an 
organization. This career path is reproduced in Figure 7 
[Ref. 65: p. 109]. In it he shows where the IC supervisor 
can become the information systems manager or can become a 
user manager. 



E. PROTOTYPING AND SYSTEM TESTING 

The purpose of prototyping and system testing is to 
ensure that what has been planned will work and to provide 
an opportunity to make any last minute changes before imple- 
mentation. This is important. An article from Datamation 
magazine supports this statement in the following quotation: 

This (advice comes) from an IBMer who has been involved 
with some big (information) centers in California: "Make 

sure all the (information) center's major start up prob- 
lems are ironed out before the user ever walks through the 
door. If the user senses the (information) center still 
has problems, it will add to his apprehension and may 
cause him to bolt and run." [Ref. 66: p. 32] 

There is more than one way to ensure the smooth opera- 
tion of the IC before implementation. One method is to not 
do anymore than a paper review. Although this is not 
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usually recommended, in some cases it is appropriate. The 
most common case is for the simple IC that provides minimal 
service. A more normal situation requires some degree of 
testing. In a more universal view of the IC, John P. Murray 
writes; "The development of the information center process 
is an evolutionary process that, in order to be most effec- 
tive, should be done in phases." [Ref. 67: p. 37] The first 
phase is the prototyping or testing phase. 

Although prototyping is the method most often mentioned 
in the literature, there are other methods to test the 
operation of the IC. In reality, these other methods are 
either partial implementations of a prototype IC or they are 
full implementations of a partial prototype. Therefore, 
only the full prototype method will be discussed in this 
thesis . 

Testing an IC prototype is the same thing as conducting 
an IC pilot study. There have been a sufficient number of 
IC pilot studies conducted to provide some insight into how 
they should be conducted. John Mele, product support spe- 
cialist at K-Mart Apparel Corporation, has been paraphrased 
as having said the following; 

A pilot project for the fledgling information center 
should be identified, he said. Ideally, the project 
should be in an area in which automation can provide 
tangible and measurable benefits. Look for a department 
that is swamped with work, has mostly manual systems in 
place and is receptive to the idea of computerization. 

Too many promises should not be offered at the outset, he 
stressed. [Ref. 68: p. 23] 
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Another article by Steve Hearn, manager of management sup- 
port services for ARCO Petroleum Products Company, gives his 
estimate of the length of time needed for the pilot study: 

The length of the pilot varies, depending of the 
preparation needed to begin support of the first user. 

Once the first user is trained, approximately three months 
should be sufficient to assess whether a long-term 
commitment should be made to the IC concept. [Ref. 69: 
p. 22] 

Because the IC concept is so unusual, the steps required 
to implement a pilot study may not be intuitively obvious. 
For this reason, the following quoted material has been 
taken from an article by Marsha Seidman, president of Crwth 



Computer Coursewares [Ref. 70: p. 9]: 

A successful pilot is usually the direct result of careful 
planning, involving the systems resources as well as 
knowledgeable product consultants. Several pilots have 
failed because of slow response time or lack of terminals. 
In one case, a lack of DASD (Direct Access Storage Device) 
space prohibited the installation of a fourth generation 
language. Here are the steps for implementing a pilot: 



1. Plan your system resources in advance: terminals, 

DASD space, CPU use, user IDs. 

2. Select a user department committed to the concept of 
end user computing. 

3. Choose a small group of highly motivated business 
professionals from the department. 

4. Select a fourth generation language. 

5. Train an information center consultant as a product 
specialist . 

6. Train the business professionals in the use of the 
language . 

7. Define objectives and the range of acceptance criteria 
that will determine the success of your pilot. 
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After the pilot study has proven to be a success, the 
usual admonitions apply. Be careful to not overextend the 
resources or the abilities of the IC staff or of the in- 
stalled hardware and software. Also be reasonably sure that 
the success of the IC can be duplicated in the full system 
environment. There would be nothing more embarrassing than 
to realize that the reason the pilot was a success was due 
to special circumstances and extra attention and that the 
production IC is a failure. It also might prove very costly 
to make such a mistake. 

F. GENERAL IMPLEMENTATION PLANNING 

In keeping with the SDLC methodology, the end of this 
phase is in reality the precursor to the next phase, the 
installation and implementation phase. Even before the 
pilot study is complete, a general plan for the next phase 
should be developed. This plan should cover general items 
that will need to be instituted. The benefit of this activ- 
ity is that it provides the opportunity to identify actions 
that must be instituted before this phase ends and allows 
for a better transition from pilot study to full operation. 

Additional equipment, hardware, software, documentation, 
and supplies should be identified. Likewise, additional 
procedures and policies should be disseminated. Finally, 
general spreading of the word and mass education of 
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potential users should be considered so as to avoid any more 
complications than absolutely necessary. 
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VI. INSTALLATION AND IMPLEMENTATION PHASE 



A. PURPOSE OF INSTALLATION AND IMPLEMENTATION PHASE 

The purpose of the installation and implementation phase 
is to transit from the present system to the new system and 
to get the new system functioning as a productive and suc- 
cessful entity. This phase results in the most detailed 
breakdown of the areas dealt with in the previous phases. 

If a pilot study was conducted, this phase puts into prac- 
tice the lessons learned from that study. It is recommended 
that this phase follow the concepts presented earlier, espe- 
cially that of incremental implementation. 

It would be virtually impossible to enumerate all of the 
considerations that should be mentioned in this phase of the 
IC implementation. Also, due to the nature of the SDLC 
study, most of the major items have already been covered. 
Therefore, this chapter will concentrate more on the unu- 
sual, innovative, and important detailed items that contrib- 
ute to a successful transition and implementation. These 
items are categorized in an attempt to provide a logical 
approach for a more complete installation and implementa- 
tion. For an IC, installation refers to putting the equip- 
ment and software in place. The manager tasked with this 
responsibility is assumed to have the necessary skills to 
accomplish this job. IC implementation, however, requires 
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special knowledge not ordinarily encountered by managers. 
Therefore,’ the remainder of this chapter will concern only 
implementation factors . 



B. INTRODUCTION 

Organizations tend to solve problems in unique ways. 
Implementing an IC is one of those problems that is subject 
to the peculiarities of these individual organizations. In 
some cases what one organization may call a success, another 
organization may call a failure. If this diversity is kept 
in mind, then what follows will make more sense. 

In an attempt to capture the overall essence of this 

phase, the first concept to be covered as part of this 

introduction is the idea of success. One author writes: 

The success of an information center depends on a service 
and entrepreneurial orientation, the right tools, the 
right people, a supportive climate, justification by the 
end user and data availability and integrity. With such 
factors going for it, the chance of success greatly in- 
creases. [Ref. 71: p. 141] 

This entrepreneurial orientation is sufficiently explained 

by the following two quotations: 

He (Ray Youstra of IBM) said the information center should 
be run as a business within a business, complete with 
marketing, measurements and a board of directors. "You 
must report back to someone high up in the organization, 
not just the DP manager." [Ref. 72: p. 22] 

As the information center begins to expand and promote its 
services, the DP manager must remain involved, setting 
directions and defining and monitoring objectives while 
also permitting the center to experiment, adjust through 
user feedback and innovate. The staff should be encour- 
aged to work directly with user personnel, treating them 
as customers and responding immediately to their problems 
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while researching new techniques and tools to meet their 
needs. [Ref. 73: p. 27] 

Success, however, is sometimes attained by learning from 
failure or mistakes. For completeness, information should 
be sought on both successes and failures. The following 
illustration lists one manager's mistakes, and offers sever- 
al good points for IC implementation: 

IC manager Joe Bochino (of European American Bank) reports 
that if he had to do it all over, he would do a few things 
differently. He would take more time to educate the IC 
staf f--teaching two or three people the entire operation 
instead of the whole staff piece-by-piece. He would make 
a separate processor available to the IC as soon as the 
pilot project was completed, instead of having to wait 
nine months as he did. He would have the data delivery 
methodology in place. He would better coordinate the 
personal computer, time sharing and mainframe disciplines 
under a single manager. He would guarantee availability 
of technical expertise by having a systems programmer 
report directly to the IC. And he would ensure that the 
IC did not start on a shoestring, and that it offered 
users secretarial and administrative as well as informa- 
tion support. [Ref. 74: p. 46] 

Tough decisions need to be made in the development of a 
successful IC. Some of these decisions will be discussed in 
the remainder of this chapter. The toughness of these 
decisions becomes apparent when one begins to appreciate the 
enormity of the task at hand. This enormity is expressed in 
the following statement made over a year ago about the 
number of available microcomputers and their associated 
software : 

There are 675 micro hardware products on the market today 
(December 1983) and 154 manufacturers, according to IRD 
(International Resource Development, Incorporated). The 
microcomputer has hit the industry with a force strong 
enough to support some 1 00 microcomputer publications and 
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employ countless third-party software developers. 

[Ref. 75: p. 16] 

The IC manager who tries to support the hardware and 
software already in place, in the organization, may be fac- 
ing a problem that has no economical solution. In addition 
to support problems, technical problems such as compatibili- 
ty may be just as difficult to solve. Even more dishearten- 
ing is the fact that many of the remaining responsibilities 
of the IC can also be tough to manage. These problems can 
only get worse if ignored. Therefore, developing the IC as 
soon as possible, harnessing the potential of end user 
computing, and controlling incompatibility often make good 
business sense. 

C. MARKETING 

The concept behind marketing is that the end users need 
to understand the IC: what it is, what it can do for them, 
and how it operates. The users need to be convinced that 
the IC is a better solution for end user computing and that 
it is not a repository for more backlogs and more user 
frustration. On the other hand, the IC staff needs "to 
promote existing capabilities without promoting new business 
that would require additional staff and facilities to sup- 
port." [Ref. 76: p. 23] There is, however, an argument 
against the need for marketing. The following two quota- 
tions support this argument: 
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Once you've started up (the IC) , you've got to fight damn 
hard to keep your credibility. If you're any good at all, 
you'll be overwhelmed with customers--they ' 11 do your ad- 
vertising for you. [Ref. 77: p. 9] 

If anything, our biggest problem was holding users back in 
order to keep from swamping our initial [information cen- 
ter] resources. We have 1800 potential end users, half of 
whom currently have access to the computer. [Ref. 78: 
p. 34] 

Nevertheless, for many organizations, there are reasons 
to consider some form of marketing for the IC. One reason 
is to dispel unrealistic user expectations. In an article 
written by Robert C. Tesch, Sr. and Debbie B. Tesch, the 
issue of user expectations for management information sys- 
tems is discussed. These researchers provide some insight 
into the importance of user expectations with the following: 

In (Michael J. ) Ginzberg's study ("Early Diagnosis of MIS 
Implementation Failure: Promising Results and Unanswered 
Questions," Management Science , April 1981), results sug- 
gest that users who hold realistic expectations prior to 
implementation are more satisfied with the system and use 
it more than users whose pre-implementation expectations 
are unrealistic. Ginzberg identifies five areas of expec- 
tations important in determining user's response to MIS: 

1 . Reason for developing the system 

2. Importance of the problem being addressed 

3. The way the system will be used 

4. Systems impact on the organization 

5. Criteria used to evaluate the system. [Ref. 79: p. 64] 
Marketing can also be of assistance in reducing internal 

conflict resulting from miscommunication and misconceptions. 
One common misconception is that technology always replaces 
people. This fear of people losing their jobs can be very 
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damaging if not controlled. Miscommunications are also 

common. The following example represents a miscommunication 

situation that could have been successfully handled much 

earlier had some form of marketing been considered: 

"Be sensitive to the possibility of conflicts," warns Jim 
DeLong, a supervisor in the information center of the 
Michigan Wisconsin Pipe Line Co., Detroit. "We weren't, 
and we alienated our own people. They'd say things like, 
'What are you doing talking to our users?' Some called us 
the 'misinformation center' for awhile .The information 
center staff recently held a meeting to explain their 
program to colleagues in other MIS sectors, and hash out 
differences. DeLong wishes they'd met a year earlier, 
before the center went into operation. [Ref. 80: p. 72] 

The following quotation shows another situation that 

needed some form of marketing support: 

"I (an information center manager) don't understand what's 
happening to our Information Center. The pilot was a 
great success, but when we opened our doors to end users 
it flopped. We're all set up to offer our services, but 
no one's buying." [Ref. 81: p. 53] 

Another insight in favor of marketing is provided by 

Gary Livingston, president of Information and Strategic 

Planning Professionals in Lakewood, Ohio: 

Managers shouldn't become too optimistic after achieving 
good initial results with the IC, warned Livingston; the 
strong beginning is usually due to the enthusiasm typical 
of pioneering users. After that it's slow going: "Thirty 

percent of the corporation, and 10 percent of top manage- 
ment, are laggards and resisters," he said. [Ref. 82: 

P. 14] 

Marketing the IC , however, can be more extensive than 
the initial advertising of the IC ' s capabilities. It can 
extend to post-implementation support as well. It can in- 
volve detailed strategy and planning and can require 
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professional management or consultation. The whole market- 
ing concept is neatly tied together in an article written by 
Marylin J. Richardson, in which she writes: 

Like any marketing strategy, one for an information center 
involves identifying the target market and then defining 
the appropriate product for that market; establishing 
where that product should be placed so the target market 
can (and will want to) access it; determining the price 
(people, time, and money) the target market can afford; 
and implementing a blend of promotional activities to 
communicate to the target market what the product is , how 
much it costs and where to get it. [Ref. 83: p. 17] 



D. TRAINING 

Training starts with the IC staff. Staff personnel must 
be trained before they are able to teach the users. Train- 
ing staff personnel can be accomplished in any manner suita- 
ble to the circumstance or organization. One unusual method 
conducted by Michael Steinberg, the information specialist 
at Corning Glassworks, is explained as follows: 

"We have found the most effective way to train our consul- 
tants in the use of a product is to find a user who knows 
just about as little about the product as our new consul- 
tant does," one member (of the IC staff) says. "We sit 
them down with a couple of reference and training manuals 
and have them learn together to develop an application. 

We find this spending a whole day with a user is very 
effective in developing that extra sense, that intuition 
kind of thing about the package." [Ref. 84: p. 30] 

Training the user is of equal or greater concern. It is 
too easy for users to choose an inappropriate software 
package for their application or even worse to misuse a 
software package. One executive using a spreadsheet package 
caused a $55 million sales figure to be in error by 
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$8 million [Ref. 85: p. 94], Although in this case, the 
error was caught early enough not to cause any problem, the 
consequences could have been disastrous. 

User training is also important because of the advan- 
tages it offers. One article claims "that users need sixty 
to eighty hours 'to figure out the computer on their own.'" 
[Ref. 86: p. 64] The same article states that this training 
can be accomplished in twenty hours through a commercial 
training workshop [Ref. 87; p. 64]. 

An even more sobering thought, is that users can not do 
it on their own. "Once new users are left alone with their 
computers, even the simplest questions can become major 
obstacles." [Ref. 88: p. 236] Therefore, not only is train- 
ing important, but follow-on training support is just as 
important . 

All end users do not need comprehensive training. It is 
important to identify the types of end users and to under- 
stand the different types of training that end users need. 
Dr. David J. Stang, Ph.D., partitions users into four 
categories [Ref. 89: p. 58]: 

1. Non-Users (Never Have) - Those who never have used a 
micro (terminal), but will soon. 

2. Non-Users (Never Will) - Those who will not be using 
micros (terminals). 

3. Surface Users - Those who only want to use micros 
(terminals), not understand them. 

4. Experienced Users - Those who understand and use 
micros (terminals). 



The types of training are expressed by the following 
quotation: 

We see end users needing five types of training: (1) data 

processing concepts, (2) quick start, (3) refresher aids, 

(4) help in overcoming difficulties of advanced use, and 

(5) explanation of the assumptions behind the models they 
plan to use. [Ref. 90: p. 4] 

These categories of end users and types of training offer 
both a method for understanding the training problem and a 
framework within which to operate. Use of these categories 
is left up to the reader. 

Training is expensive. This point is clearly presented 

in the following two quotations: 

To get a good trainer these days , you may have to spend 
quite a bit. For an in-house person salaries have risen 
steadily in recent years--$24 , 300 (1979), $27,200 (1980), 
$29,300 (1981), to $31,900 (1982)--and probably continue 
to climb. But far more expensive than in-house training 
is an outside consultant, whose rates will range anywhere 
from $100 a day to $2,000 an hour. In short, training can 
be expensive, though perhaps not as expensive as the 
ignorance it can replace. [Ref. 91: p. 56] 

Ferrin (Corporation) has found that it can take anywhere 
from 20 to 1 00 hours for a person to get up to scratch on 
the basic operation of a single pc program, like a spread- 
sheet or database package. The company figures that the 
average cost to a corporation is $40 per hour per student, 
and the total learning cost can reach $800 to $4,000 for a 
single corporate pc user. There's also the added cost of 
the other people that get involved in helping users, such 
as department colleagues, in-house computer professionals, 
and outside organizations like Ferrin (a pc services 
firm) . Ferrin calculates that additions like these can up 
the total learning cost to between $1,000 and $6,000 per 
user. And that's just for one package. [Ref. 92: p. 135] 

Faced with expenses of this magnitude, one cannot help 
but wonder what are the training options. Although only one 
of the options mentioned in the following list will be 
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discussed in any detail, any one of these training options 
may be appropriate under the right circumstances [Ref. 93: 
p. 24]: 

^ . Formal classroom 

2. One-on-one tutoring 

3. Computer-based 

4. Videotape-based 

5. Interactive video disk 

6 . Independent study 

7. Contractors 

The one training option that will be discussed is option 
number 3, computer-based training (CBT). This option seems 
to meet more of the IC needs than any other. It is more 
effective than other methods, lends itself well to large 
user organizations, and has a strong capacity for simulation 
[Ref. 94: p.18]. CBT allows the user to become familiar 
with a software package by working through an interactive 
software program. This program will not only feature the 
kind of knowledge required to use a software package, but it 
will often be composed within the package it is designed to 
teach. It will often hand-walk the user through the package 
on the actual system that the user will be using. Most 
initial CBT packages were designed for mainframe end user 
computing, but more are becoming available for 
microcomputers as well. Some CBTs , called authoring sys- 
tems, allow the organization to develop and modify the 



training package to meet the specific needs of the 
organization. Other CBT packages are unalterable. 

CBT is often the preferred method for training because 
of its centralized distribution, administration, and moni- 
toring capabilities: 

It (CBT) easily accommodates changes in course material. 

It allows trainee performance to be centrally monitored 
and administrative records to be automatically updated. 

And it permits a high degree of interaction between stu- 
dent and system, according to Christopher Howey , a pro- 
fessor of instruction and training technology at Governors 
State University in Park Forest, 111.... it (CBT) lends 
itself well to large user organizations that have to 
disperse their instructional material to many employees 
over a wide geographic area, (Gary) Brown (vice-president 
of CRWTH Computer Coursewares, Inc.) said. [Ref. 95: 

p. 18] 

...users can reportedly transmit CBT course material back 
and forth between their central and remote computing in- 
stallations. From a user's standpoint, the advantage of 
having such an uploading and downloading capability is 
that it provides a "centralized means of managing instruc- 
tional resources," according to professor Christopher 
Howey of Governors State University in Park Forest, 111. 
"Large organizations need to be able to centrally store 
results so they can decide which employees are qualified 
to receive a particular type of training and which 
aren ' t . " . . . In addition, CBT development tools may soon 
gain the ability to upload personal computer-generated 
courseware to a large-scale CPU, where the material would 
reside centrally as a "data file in a data base management 
system [DBMS]," (Gloria) Gery (vice-president) of the 
Courseware Developers, Inc., in Manchester, Conn.) pre- 
dicted. If a stored lesson later required revisions, the 
owner would need merely to rewrite its one mainframe- 
resident copy and then could immediately distribute up- 
dated versions of the courseware to all remote end users. 
[Ref. 96: p. 22] 

CBTs can save money by teaching users without requiring 
the services of a staff trainer. They are also more indi- 
vidualistic than the classroom environment and eliminate the 
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personality problems of one-on-one training. Nevertheless, 

there are some reasons for not using CBTs . One is that they 

cannot replace the human touch. But, until just recently, 

they had not been of very good quality. Gary DeWard Brown, 

executive vice president of Crwth Computer Coursewares, a 

CBT vendor, gives some guidance in this area: 

Combining instruction with hands-on experience, CBT is 
potentially the ideal vehicle for teaching end users com- 
puter skills. However, just because a course is presented 
through CBT does not guarantee effectiveness. The quality 
of a CBT course for end users will depend on the following 
three points [Ref. 97: p. 10]: 

1 . Does the course address the target audience? 

2. Is the subject matter well presented? 

3. Are the strengths of the medium fully exploited? 

Of course, CBTs are more complicated than is suggested. The 
only sure way to ensure that a CBT meets the IC ' s needs is 
to use the CBT and form a judgment based on preference. 

There are two additional items worth mentioning when trying 
to evaluate a CBT. The first is the ratio of question 
screens to text screens. The current thought is that ideal- 
ly the user would like to see a 1:1 ratio [Ref. 98: p. 15]. 
The second item is that a workbook can be a valuable asset 
to the casual user [Ref. 99: p. 32]. 

In creating CBTs for novice users, Gary DeWard Brown 
uses some assumptions about users that helps his company to 
develop a good product. These assumptions are paraphrased 
in the following list because they give a perspective 
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towards training users that may be helpful in the selection 
of the proper training method [Ref. 100: pp. 13-14]: 

1. Users are intelligent. 

2. Users have never used a computer before. 

3. Users are interested, but impatient. 

4. Users have a sense of humor. 

5. Users will make mistakes. 

6. Users need to understand some DP terms. 

7. Users need to know when to use a computer and when not 
to use one. 

8. Users need to know about security and backup. 

9. Users need to know computing costs. 

End user training is not without its problems. One of 
the most difficult problems to solve is how to satisfy the 
end user that has no patience. "'End users want to be able 
to learn enough to get up and going on their own projects in 
a day, a half-day if they can. And most would like to be 
able to learn it all in 30 minutes,' observes (Bob) Richter 
(IC consultant and trainer for Deltak, Inc.)." [Ref. 101: 
p. 50] Another problem concerns the user's capacity and 
desire to learn different software packages. Merlyn Vaughn, 
vice president and general manager of Systems Software 
Division of Walker Interactive Products, capsulizes this 
problem : 

It is unreasonable to an end user to learn several differ- 
ent products to meet his basic information management 

needs. While DP professionals might be used to frequent 
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conversions and a multiplicity of human interfaces, the 
end-user will not tolerate such an unfriendly environment. 
Usually, the first tool learned will be the tool that the 
user will want to stick with, and with which he will wish 
to meet his needs .... Inf ormation Centers that I have come 
across that have tried replacing several tools with fewer 
multi-purpose products, have found it difficult to wean 
their customers from the old tools, and the proliferation 
is compounded. [Ref. 102: pp. 28-29] 

John Seymour provides a "pseudo" solution to the problem of 

weaning end users from the software packages already in 

place, by the following method: 

Don't try (to wean end users). Make the end users learn 
at least two of the spreadsheets available, or two of the 
word processors for starters. They may not want to use 
both, but the benefits are still positive. First, you get 
greater back-up, transferability of skills, and compati- 
bility of knowledge. Second, the users by learning just 
one other package, broaden their overall capability and 
understanding enormously. [Ref. 103: p. 38] 

Sharing the experiences of others is a powerful educa- 
tion tool. With this thought in mind, four quotations 
relate interesting training experiences of others: 

They (Inland Steel's IC) discovered, however, that day-to- 
day problems demanded time from the (information) center 
staff, and turned to computer-based training to clear 
staff for support to users.... Now they (Inland Steel) have 
appointed one end user in each department to be a "user 
specialist," who gets advanced training and then supports 
between eight and 15 users in that department. [Ref. 104: 

p . 16 ] 

Training (at Exxon Corporation) is geared to clients' 
schedules. Courses are also designed to give a working 
knov/ledge of tools without turning clients into technical 
experts. Each course maximizes- hands-on student exercises 
and minimizes lecture sessions, and no course is longer 
than one day. Each class is limited to four people, and 
for clients with seniority, classes are available on a 
one-on-one basis. There are no published class sched- 
ules--a class is taught when two or more clients have 
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requested it and an instructor is free. Waiting time to 
take a class is typically less than two weeks. [Ref. 105: 
p. 138] 

Three end users from (Graco Incorporated's) marketing went 
back to their department after learning the basics of the 
system and immediately showed other department members how 
to access and use the applications they had built soon 
after the (three day) training session. In a matter of 
days, members of marketing were utilizing the information 
center service. [Ref. 106: p. 27] 

"In the formative stage of an information center," says 
Richard Crandall, president, Comshare, Inc., Ann Arbor, 

MI , "it is feasible to handle the user training needs with 
one or a few instructors," using traditional classroom 
training. However, this method becomes impractical as two 
major developments occur. First, larger numbers of end 
users require training in even larger numbers of software 
products ....( Second ) There are more "occasional" computer 
users who require refresher courses at least once a year. 
[Ref. 107: p. 32] 



E. STAFFING AND CONSULTING 

Many IC staffing issues are commonly found in any staff- 
ing situation. Examples of these issues are the hiring of 
temporary help, hiring from inside the organization or from 
outside, and determination of skills required. There are, 
however, a few requirements that are peculiar to the IC. 

One is that the staff needs to have patience, good "tube- 
side" manner, and should be interested in end results rather 
than the technology that achieves it [Ref. 108: p. 28]. 

The important part of IC staffing revolves around the 
consultants. IC consultants are the main interface between 
end users and the IC. They need to be placed near the end 
users for convenient access [Ref. 109: p. 29]. The consult- 
ants need to guide the end users in the appropriate software 
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to use for the application and they need to support the data 

processing department and refer large applications to the 

data processing department. Exxon Corporation accomplishes 

this in the following manner; 

When clients come to the CSC (IC) for advice on a new 
application, a team member discusses the problem with them 
and evaluates how best to handle their needs. For 
straightforward applications, the CSC (IC) member simply 
recommends an approach or a tool. For more complex prob- 
lem.s , a second CSC (IC) member is usually called in to 
help. If the application is complex enough to require 
contracting for conventional development by systems pro- 
fessionals, the client is directed to the appropriate 
people in other parts of the organization. [Ref. 110; 
p. 138] 

Another important consideration is determination of the 
level of support to be offered. Although this is also 
situation dependent, it is generally thought that consult- 
ants should not program for the end users. Jeffrie Shelley, 
manager of the IC at the Chicago Transit Authority, claims 
that "The information center staff shouldn't do any coding, 
or it will develop its own bac>;log." [Ref. Ill; p. 14] 

Those managers that do not object to consultants doing 
coding for end users, often place restrictions on coding so 
that consultants are only minimally involved. The majority 
of IC managers seem to follow the advice in the next two 
quotations ; 

(Dennis) Mills (information center supervisor at John 
Deere Component Works) warns MIS/DP managers not to allow 
the IC to become a programming department for ad hoc or 
one time requests. If the IC is to achieve its original 
goals, questions that begin, "Can you do..." must be 
changed to "Will you help me...." [Ref. 112; p. 141] 
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Information centers should limit their support activities 
to providing end users with in-house consulting serv- 
ices .... (Warren) Brown (MIS director at Hercules Incor- 
porated aerospace division) urged information center staff 
members to avoid intensive involvem.ent in their clients' 
software development projects .... "We don't create any 
deliverables," Brown said. "We're striving for user self- 
sufficiency. Our goal is to help users to help them- 
selves." [Ref. 113: p. 10] 

Since the availability of consultants and the consisten- 
cy of their advice varies from organization to organization, 
some examples of how corporations treat these requirements 
have been provided: 

Because of its size and purpose, the CSC { IC at Exxon 
Corporation) does not write applications for its clients; 
that would not facilitate "end user" computing. And while 
CSC (IC) services are available on call, there is a four 
hour limit on consultation or technical assistance per 
application. This ensures that no single user monopolizes 
the center. [Ref. 114: p. 138] 

Two service consultants operate the wall<.-in facility from 
8 am to 4:30 pm every working day, although employees can 
arrange to use the center 24 hours a day, seven days a 
v;eek. The consultants conduct required introductory 
classes for center users and specialized courses in the 
various software tools. They also assist in designing 
initial applications and applying the tools. [Ref. 115: 
p. 28] 

To help ensure consistency and accuracy in consultations, 
the CSC (IC) team mfeets once a week to compare notes on 
significant recommendations. This meeting also enhances 
the team's education v/hile preventing any one member from, 
overselling the tool that he or she normally supports. 
[Ref. 116: p. 138] 

The final issue to be considered in relationship to 
staffing and consulting is that of the required number of 
consultants. This number is usually expressed as the ratio 
of consultants to end users. Van Bakshi, an instructor with 
the IBM Information Systems Management Institute, claims 
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that "the average ratio of information center consultants to 
end users is about 1:35, with a ratio of 1:100 prevailing in 
the engineering world." [Ref. 117: p. 24] Vaughn Merlyn, 
from Walker Interactive Products, provides the following 
insight : 

Consul tant-to-customer ratios depend upon many factors, 
including the type of customer, the tools, and the 
maturity of the Information Center. A good working 
number, for planning purposes, is around one consultant 
for every fifty users. However, there are many exceptions 
to this rule, particularly during the earlier stages of 
Information Center growth when a lower ratio is desirable. 
[Ref. 118: p. 27] 



F. HARDWARE 

Much has been written about IC hardware, especially 
microcomputers. Therefore, treatment of this topic will be 
light. At this level in the SDLC, policy and detail are 
important. Hardware can be helpful or it can hurt the IC, 
depending on the way it is controlled. If control is too 
tight few people will use the IC. If control is too loose, 

the IC will turn into a gigantic expense with little return 

on investment. There is no perfect amount of control. 

Again it is si tuationally dependent. A comparison between 
computing power and costs is made in the following article 
extract : 

On a large, heavily loaded computer running TSO , the 
incremental hardware cost to provide adequate response for 
five additional users might be $500,000. To give the same 
five users even better response with five micros would 
cost even less than $25,000, with a letter-quality printer 

thrown in for each. [Ref. 119: p. 96] 
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Although this is not a complete cost/benefit analysis it 
does provide a sample of some of the type of trade-offs that 
involve hardware in the IC. The high cost of IC hardware 
often causes frequent scrutiny and requires effective utili- 
zation. The following quotation addresses the effective 
utilization of personal computers: 

Giving a personal computer to someone who is not 
interested in one, regardless of whether or not the person 
falls into the targeted group, is flushing money down the 
drain. ... today ' s PCs require an interest high enough to 
get past the very frustrating and clumsy learning 
curves.... On the other hand, denying one (PC) to someone 
aggressively interested, again regardless of targeted 
groups, is just as big a waste. If necessary, such people 
should be moved organizationally before they are flatly 
denied access. The aggressively interested employee will 
find productive uses for the PC that no one else dreamed 
of. [Ref. 120: pp. 35-36] 

Some organizations are loaning microcomputers to employees 
to cover peak demand periods, as a backup for broken micro- 
computers, and as a means to test out a new piece of equip- 
ment [Refs. 121: p.15, 122: p. 82, 123: p. 16]. Some even 
are letting employees take microcomputers home [Refs. 124: 
p. 82 , 125: p. 36 ] . 

One of the most talked about topics is personal computer 
compatibility. Compatible computers allow sharing of pro- 
grams and data and can be connected for communication 
between themselves and mainframes. The degree of compat- 
ibility, which is often overlooked, needs to be examined 
more closely. The following excerpt explains: 

The unseen disease in the swift proliferation of personal 
computers is the complication of incompatible products 
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that appear to be compatible. Suppose everyone in the 
organization had been carefully restricted to the IBM PC, 
LOTUS dBASE, and WORDPLUS. We're in great shape, right? 
But half of them are running under DOS Version 1 , some 
under Version 1.25, and the rest under Version 2. 
Associated versions of the application products run on the 
appropriate machines. Some of the software has bugs that 
were fixed in later versions. Some use color, some don't. 
Some allow careful disk organization under subdirectories, 
some don't. But everyone is using the same products. Is 
a rose still a rose...? And this is the easy case where 
everyone is using one machine and one set of products. 

But the disks and files are not interchangeable, even 
here. [Ref. 126: p. 39] 

At United Technologies Corporation, John Bennett, the DP 
director, describes a minimum compatibility policy as 
follows : 

Given this loose structure, there are no corporatewide 
preferred vendor lists, said Bennett, as each division has 
settled on the type of equipment that it feels is most 
beneficial. The only corporate policy is that the PC have 
a minimum of 256K bytes of RAM, a graphics card, printer 
and high resolution monitor. [Ref. 127: p. 51] 

IC managers should be concerned with other hardware 
details as well. The IC should educate their end users on 
the proper care of diskettes (e.g., no bending, no touching 
the magnetic surface, use only felt tip pens to write on the 
labels, use backup procedures often, store backup copies 
off-site, and avoidance of magnetic objects) and other 
equipment. The IC should ensure adequate quality power is 
available, provide and teach security of equipment and data, 
and provide any other necessary guidance. 

The IC manager should install policies where necessary. 
The following policy, which will lead into the topic of 
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software, is mentioned because of the unique approach it 
displays : 

The CSC (IC) does not have the authority to dictate which 
tools to use. To provide thorough support, however, the 
CSC (IC) must limit its tool set to a manageable size. 
Therefore, the CSC (IC) has a simple policy; if clients 
use the tools recommended by the CSC (IC), the door is 
always open, and the CSC (IC) will provide complete and 
comprehensive service. If clients use brand X of their 
own choosing, the CSC (IC) will provide only minimum 
service and then only after meeting the needs of its 
regular clients. This policy, applicable to both hard- 
ware and software, has been quite successful. [Ref. 128; 
pp. 138-140] 



G. SOFTWARE 

Choosing the right software can mean the difference 
between success and failure for an IC. Allowing end users 
to choose may result in the use of bundled software that 
came with the user's personal computer regardless of how 
good or how appropriate the software may be [Ref. 129; p. 
43]. Even worse, the end users may be using each other's 
software illegally. John Seymour writes the following on 
this topic; 

A recent magazine article indicated that there are 150,000 
registered copies of a leading database package in use and 
at least that many in use that are not registered. I'd 
bet the estimate of unregistered copies is very 
conservative. On a corporate scale this is grand larceny. 
[Ref. 130; p. 42] 

The software developers are starting to pursue flagrant 
corporate abusers and taking them to court. Most corpora- 
tions can afford the resulting fines but can ill afford the 
corporate embarrassment in the public sector. One firm. 
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Pacific Gas and Electric Company of San Francisco, solves 
the software piracy (illegal copying) problem with what has 
been termed a software site license as described in the 
following : 

We don't buy a copy of the package, we buy the right to 
use it. In exchange, we make sure our users will not call 
the vendor; we take over the support f unction .... so far 
the vendors have been amenable to a single, up-front 
payment, along with specified payments for upgrades. "We 
do not pay per copy royalties," Buckholtz said....PG&E 
also pays for the right to reproduce manuals for the 
software. [Ref. 131; pp. 95, 100] 

Corporations that are interested in controlling software 

piracy can follow the five steps suggested by G. Gervaise 

Davis III and paraphrased as follows [Ref. 132: p. 82]: 

1. Create a written policy. 

2. Communicate that policy. 

3. Look around the company for violations. 

4. Take action if piracy occurs. 

5. Work with software developers (e.g. site licenses). 

It is helpful to put software costs in perspective by 

comparing mainframe software to microcomputer software. A 

simple comparison is provided below: 

An obvious difference between mainframe and micro software 
is cost. Many mainframe packages sell for about $80,000 
to $120,000. Most micro packages, by contrast, cost 
between $30 and $1,000. The individual price tag, 
however, may be deceiving. MIS executives usually 
purchase only a few copies of a mainframe package, but 
micro software is often purchased in volume. If there are 
300 pcs in your organization and you decide that each one 
should have a copy of a selected $300 package--bingo I 
You've just spent $90,000. [Ref. 133: p. 74] 
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The last software detail to be discussed is integrated 
software. "Integrated software refers to software that 
meets two minimal conditions: it offers two or more major 

applications and allows information to be transferred be- 
tween these applications with a minimum of effort- -perhaps 
five or 1 0 keystrokes and in one or two minutes." [Ref. 134: 
p. 59] The benefits of integrated software are paraphrased 
in the following list [Ref. 135: p. 60]: 

1. Requires less learning. 

2. Eliminates the need for entering data more than once. 

3. Offers three to six major applications at a cost per 
application far lower than the unit cost of 
independently purchased software. 

4. Moving from one task to another may require only a 
keystroke of two. 

Not everyone wants integrated software. This is a difficult 
idea for an IC manager to accept. One vendor states: "What 

we're seeing is a rebellion against integrated packages 
forced onto people who don't need them." [Ref. 136: p. 20] 
What some people are finding is that integrated software is 
more complicated and therefore is more difficult to use. 

When a simpler package can meet the needs of end users, they 
do not want to be stuck with the more difficult package. 

H. MANAGING AND CONTROLLING 

Many items can fit under the managing and controlling 
category. One very controversial topic in this area is data 
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access. The logic of those in favor of direct access is 

amply explained in the next quotation: 

"The only way that information centers, and personal 
computers tied to information centers, can reach their 
true potential is by way of easy access to the corporate 
database," we were told. "And this means the database 
itself, not an extract version of it." An extract version 
may not be up-to-date, or may not have the data that a 
particular user urgently needs, they said. [Ref. 137: p. 5] 

There is, however, a more popular approach, which extols the 

virtues of extract files or databases. The following are 

examples of some of these virtues: 

When an extract of the production file is taken, data 
values can be put in a standard format, obsolete fields 
can be stripped off, control totals can be checked to 
ensure accuracy and various computations can be performed 
as requested by the user. [Ref. 138: p. 56] 

Two ways that extract files and databases are handled are 

indicated in the following two statements: 

(John) Nylen ( IC supervisor at Signode Industries) 
protects corporate data by not allowing any of the end 
users access to the production files during the first 
shift processing. Anyone who does development work 
accesses extracted versions of those files. If they wish 
to run against the full production file, they submit the 
job and it runs in batch at night. "We more or less have 
next day Keporting," he explains. "That's served our 
purposes well, however, because people previously were 
used to three to six months." [Ref. 139: p. 27] 

Users (at the Brazilian subsidiary of the Chase Manhattan 
Bank, Banco Lar) cannot access production data without 
first filing a request with the information support center 
(IC). The support center (IC) staff defines the fields 
that are needed from the central data base and copies them 
to a disk that is accessible from the user's virtual 
machines. [Ref. 140: p. 29] 

Another area of managing and controlling is the concern 
for what the end users are doing with this technology. 
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Three unusual aspects dealing with computers as status 
symbols, the problem of "technostress", and technology in- 
fatuation are explained well in the following quotations: 

...computers and word processors have become status 
symbols to everyone from secretaries to engineers and from 
analysts to executives. The status has been refined 
beyond the Cadillac and the Mercedes'. There is anxiety on 
the part of those who don’t have them yet, made worse by 
the owners who emphasize how easy they are to master. The 
easier everyone says they are, the easier it will be to 
look stupid. [Ref. 141: p. 34] 

Technostress ... is defined as the inability to adapt to 
computers. (Craig) Brod (author of a book on 
technostress) identified two forms of the phenomenon. The 
first is the feeling of being overwhelm.ed by the machines 
and is not confined to the working level, but extends all 
the way into the executive offices. The second results in 
people becoming machine-like, in that they overidentify 
with the computers and lose the interpersonal skills that 
enable them to deal effectively with people. [Ref. 142: 
p. 54] 

User department managers must monitor whether users are 
using information center tools as their daily work rather 
than as a useful augmentation. "Users become so engrossed 
in the process, and how much fun it is, that they are 
constantly doing gee-whiz things," confirms one 
information center manager, "and the grunt work doesn't 
get done any more." If that happens, the information 
center can consult with the user's department manager to 
see if the applications can be simplified or eliminated. 
[Ref . 143: p. 26 ] 

Microcomputers have their strengths and weaknesses when 
compared to other mediums for accomplishing a task. One 
weakness to be guarded against and which gradually occurs is 
demonstrated in this example: 

The micro also has bad side effects. It turns each person 
into a combination computer operator, data entry clerk, 
and programmer. As one chief financial officer said, "I 
hired this person as a $75 , 000-a-year financial analyst, 
and the micro turned her into a $25 , 000-a-year 
programmer." [Ref. 144: p. 98] 
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IC managers have some problems, also. The full brunt of 
managing the proliferation of microcomputers does not neces- 
sarily have to rest on the shoulders of the IC manager. 

Marty Maffeo, IC manager for Polaroid Corporation, supports 
this concept with the next statement: 

Unlike many Fortune 1000 companies, Polaroid's PC strategy 
is implemented through a committee of users. And, despite 
the fact that government by committee has often been 
called the perfect way to get nothing done, Polaroid's 
Marty Maffeo said it is the ideal system for his company. 
[Ref. 145: p. 60] 

There are many administrative tasks that impact on the 
IC either in staff time or in other resource utilization. 
Tasks, such as publishing a newsletter, handling supplies, 
maintaining libraries, and organizing users groups, quickly 
expand to consume more staff resources than allocated. The 
two IC managers, Marie Sv7anson and Ann Staton, at First 
National Bank of Minneapolis, agree that this is the case in 
the follov/ing: 

A big surprise was the amount of "administrivia" involved 
with running their "business within a business." Says 
Swanson, "Nobody told us how much time it takes to do the 
class scheduling, promotion, billing, publicity or any of 
the day-to-day activities that have to be done, but that 
interfere with the actual work of the information center." 
[Ref. 146: p. 49] 

John Seymour writes about the administration of software: 

The administration of purchased software, especially in 
the volumes at which it is being purchased, is a signifi- 
cant task. The packages need to be registered by serial 
number with the vendor. Updates and new versions need to 
be given serious consideration before distribution is 
made. Add-on training or regular news bulletins advising 
users must be made available. [Ref. 147: p. 40] 
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Exxon Corporation performs an administrative task that helps 

ease the tension between the applications development staff 

and the IC through the use of a log. The ensuing statement 

provides a more detailed account of how this log is used: 

Creating a log of CSC (IC) contacts vjith clients, which 
included a brief description of the meeting and any ac- 
tions taken, was central to improving communication be- 
tween the CSC (IC) and other departments. CSC (IC) 
members were free to handle clients' problems directly if 
the solution v/as clearly suitable for end-user computing. 
All contacts, however, were to be logged, and appropriate 
applications development staff was to be notified immedi- 
ately if a problem could be best solved by them. The log 
was distributed monthly to the applications development 
group and to other interested parties so they could follow 
up on any CSC ( IC) activities deemed appropriate. 

[Ref. 148: p. 142] 

To conclude the topic of managing and controlling, two 
items connected to financial considerations of an IC are 
presented as follows: 

Among (Ray) Youstra's (from IBM) suggested techniques for 
tracking information center performance is an on-line 
questionnaire, which he said is easy for users to answer 
and can be directed to a selected subset of users. He 
recommended that information center management and end 
users adopt a services agreement, detailing hours of serv- 
ice, expected response times and user responsibilities. 
"Any system can be built to give you subsecond response 
time--all it takes is money," Youstra said. [Ref. 149: 
p. 22] 

In successful information centers, financial considera- 
tions receive full attention and support. Financial mat- 
ters become crucial when considering that in most cases, 
organizations underestimate start up costs by as much as 
60 percent and recurring costs by as much as 40 percent. 
[Ref. 150: p. 36] 
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OPPORTUNITIES 



I . 

The topic of opportunities requires examination of the 
latest technologies and it also requires an imaginative look 
at productivity. The concept of the IC is based on enhanc- 
ing end user productivity. The scope of IC responsibility 
seems to be broadening to include office automation. The IC 
is a logical place to provide centralized control of basi- 
cally decentralized functions and, therefore, is as good a 
place to assign office automation responsibilities as any- 
where else. The opportunity for productivity is great. 

"Over 50% of employed Americans are office workers in cleri- 
cal, management, professional or semiprofessional posi- 
tions." [Ref. 151: p. 18] But before the IC starts to 
improve productivity by using technology, it should ensure 
that other means have been reviewed. The following facts 
explain what this means; 

Proper lighting and office design can increase office 
productivity up to 30%, according to Charles Smith, presi- 
dent, National Assn, of Accountants. A well-administered 
personnel policy involving motivation and incentives can 
add 20%. [Ref. 152: p. 18] 

The need for new technology is evidenced by the pressure 
for the IC to provide electronic and voice mail systems is 
steadily growing. "Telephone tag" is the process of two 
people trying to get a hold of the other, and the other 
person is always unavailable. People are becoming more 
impatient with the inefficiency of the present telephone 
system and want a solution. As one author writes: 
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. . .about 52 percent of all telephone calls in the office 
are uncompleted on the first try. The game of "telephone 
tag" is a most frustrating waste of tim.e. [Ref. 153; 
p. 139] 

These new solutions may not stand up to their promises. 
Evelyn Wilk, Senior Manager of Arthur Anderson and Company 
claims: 

"Right now you can tie 1 00 personal computers together and 
you don't really have anything except physical connects 
and shared files," said Wilk. "All of the pieces are 
there but you don't have a system. You don't really have 
a file management program or transparent capabilities. 
[Ref. 154: p. 20] 

Another deception may be in the area of response times. 

Compare the following two quotations: 

...there is no agreement as to what constitutes acceptable 
response time; it depends on how long one is willing to 
sit at a terminal and wait for the computer to reply after 
a request is entered. A lot of factors influence response 
time, including the hardware, software, and the nature of 
the inquiry. For the most part, response times in the 
two-second range are great , three to six seconds are 
tolerable, and more than eight or nine seconds irritating, 
depending on the application. [Ref. 155; p. 108] 

Computer scientist Ben Shneiderman, for one thinks quick 
response times can lower productivity in many cases.... To 
back his claim that slower can be better, Shneiderman 
cited studies that found user error rates can jump when 
response times are quickened, particularly involving com- 
plex tasks. He cited a Bell Laboratories study that 
turned up an optimum response time of 12 seconds for a 
specific application. [Ref. 156: p. 14] 

There is potential for poor productivity in one often 
used segment of end user computing. That segment is genera- 
tion of graphics. If not controlled properly, graphics can 
be costly and time consuming. Two examples of this phenome- 
non are: 
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But graphics are also easy to misuse. There are numerous 
instances where senior-level end users spent a half hour 
or more in front, of a crt to get one graph just right or 
tried to use a tv;o pen plotter to create several transpar- 
encies at one sitting. These situations are a waste of 
time and manpower because an administrative group now 
exists to create such charts. The CSC (IC) is now 
searching for more user-friendly graphics tools while 
instructing clients on using the current ones more effec- 
tively. [Ref. 157: p. 142] 

A bank vice president creates slides, almost instantane- 
ously, for 30 cents each. The old, traditional approach 
took several days and cost $35 per slide. She now uses 
slides for routine presentations rather than only on spe- 
cial occasions. [Ref. 158: p. 246] 

Beth A. Benson, a financial graphics programmer at Johnson 

and Johnson, has captured the topic of graphics use in the 

following quotation: 

We had an established need for some level of graphics 
because management was overloaded with paper and computer- 
generated reports; it needed to see less de.tail and more 
trends. Some of our users were creating charts manually 
on a routine basis, while presentation graphics were con- 
tracted out to a printer .... Computer graphics applications 
are increasing constantly. As companies grow and the 
amount of data increases, the need for simplification and 
exception reporting increases. [Ref. 159: pp. 47-48] 

The last opportunity to be examined is a particular 
system installed at the University of Texas Law School. It 
is described as follows: 

The Kurzwell scanning and processing system is different 
from other OCR (optical character recognition) scanning 
systems because it can scan and recognize almost any font 
in typewritten or typeset materials in sizes ranging from 
small six-point type to relatively large 24-point type.... 
In this way, rekeying is eliminated, saving both time and 
typographical errors. [Ref. 160: pp. 128-129] 
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VII. REVIEW PHASE 



A. PURPOSE OF THE REVIEW PHASE 

The purpose of the review phase is to evaluate the 
effectiveness of the SDLC and the management techniques 
applied, and to determine whether projected benefits have 
been utilized and whether enhancements are desirable and 
justifiable. 

B. DEVELOPMENT RECAPITULATION 

The objective of this activity is twofold. The first 
requirement is to determine the appropriateness of the SDLC 
methodology to the problem of end user computing. The 
second requirement is to evaluate the degree of success of 
the project development team in the utilization of the SDLC 
methodology and the documentation of mistakes for future 
reference . 

Determination of the appropriateness can be difficult. 
As one author states: 

Analytical and modeling techniques that were inadequately 
understood and improperly applied by planning profes- 
sionals will soon be applied even more improperly by 
staffs throughout corporations.. Few practitioners under- 
stand the limitations of business analysis and modeling. 
Now, anyone can have at desktop enormous computer power. 
This distributed computer power combined with the naivete 
bodes national economic mayhem. [Ref. 161: p. 9] 

The prejudice of ignorance is difficult to overcome. In 

addition to ignorance, there is another prejudice which 
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should be avoided. This prejudice is loyalty to a particu- 
lar methodology. It is like the child who tries to force 
the square peg into the round hole; it does not work very 
well. John Seymour adds some commentary to this idea: 

And we all have our religions when it comes to methodolo- 
gies, implementation techniques, brand names, and stand- 
ards for judging who's good and who isn't. And most 
methodologies work under the right circumstances, and fail 
under the wrong ones. [Ref. 162: pp. 15-16] 

The second requirement, to determine how well the SDLC 
study methodology was utilized, can be based on a brain 
storming session at the end of the study and an examination 
of the documentation that was accumulated throughout the 
project. Complaints from team members, the length of actual 
development time, and the amount of duplicated effort are 
all indicators of the team's performance. 

C. POST IMPLEMENTATION REVIEW 

The purpose of this review is to evaluate how well the 
system has performed in meeting original expectations and 
projections for improvement, and to identify any maintenance 
projects that should be undertaken to improve or enhance the 
implemented system. In other words, it is a review of how 
well the IC is doing, and what else can be done. 

This review should be formal in nature and should be 
conducted at appropriate intervals to be decided at the end 
of the implementation phase. It should include an examina- 
tion of productivity measurements, a review of any audits 
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conducted, a review of the use of the latest technology, and 
an evaluation of a survey of the end users. The business 
objectives should be reconsidered in case there has been a 
change, and also to reinforce the basic underlying premise 
of the purpose of the IC. Lastly, there should be some 
provision to conduct partial reviews whenever the situation 
changes or the circumstances warrant. 
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VIII, CONCLUSION 



A. GENERAL OBSERVATIONS 

The IC seems to fill a gap in the traditional management 
structure of most organizations. The traditional hierarchi- 
cal organization lacks the ability to control and maximize 
the productive use of end user computing. It would be 
easier if these organizations were organized around func- 
tional capabilities vice the normal departmental structures 
or product lines. Most organizations find that the func- 
tions provided by the IC help to cross rigid departmental 
boundaries but have potential to cause problems if not 
properly controlled. As one author writes: 

Information is such a critical resource that some com- 
panies find its care can no longer fall under several 
different, and sometimes uncoordinated, domains. These 
businesses are setting up information centers that not 
only help users, but also draw all aspects of information 
processing under one umbrella. [Ref. 163: p. 75] 

Even the manner in which an IC is implemented can affect the 
productivity of one department over another and can make a 
major impact on the corporate strategy. Some control, how- 
ever, is better than none, and implementing an IC is almost 
always more productive than not implementing an IC. Vaughn 
Merlyn supports this idea when he writes: 

The vast majority of Information Centers are implemented 
below "par", and it seems that there are two "laws of the 
Information Center" that are inescapable. The first law 
is, "It is virtually impossible to implement an 
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Information Center so badly that it will not experience 
success early in its life." The second law states, "It is 
virtually impossible to implement an Information Center so 
well that it will not experience significant problems 
later in its life." [Ref. 164: p. 29] 



End user computing expertise is often lacking. General 
managers find not only the technology difficult to master, 
but the unique management requirements are equally burden- 
some. This is partially because the IC concept is new. 
Likewise, the amount of resources required, to remain cur- 
rent in the fast moving field of computers, is prohibitively 
uneconomical for most departments and requires the resources 
and coordination of a larger body, usually the corporation 
itself. Mostly, because of these reasons, ICs are gaining 
popularity and, in some cases, are approaching the status of 
being a necessity; 

IBM claims that 42 percent of its largest computer users 
have these centers (ICs), and a recent survey of 32 major 
companies found that two-thirds expect to support two or 
more information centers by 1985. [Ref. 165: p. 30] 



It is estimated that some 40 percent of mainframe instal- 
lations in North America have Information Centers--whether 
or not under the name--in place. The majority of the 
balance are planning to establish such centers. The cor- 
porate use of personal computers is also spreading. 

[Ref . 166: p. 12] 



Management is also finding that end users can not be 
stopped in their fervor for end user computing. End users, 
left to their own devices, often misuse the technology 



because of lack of skills or knowledge, poor application of 
resources, or infatuation with the technology. This results 
in suboptimal productivity and poor return on investment. 



Control, often in a form similar to the IC, is usually 
required . 

In a survey conducted in 1982 and updated in 1984, 96 
northeast Ohio organizations answered questions about per- 
sonal computing. These businesses showed gross revenues 
ranging from $50 million to over $2 million. Figure 8 shows 
the results of this survey. Because this survey was not 
scientifically generated or analyzed it can not be con- 
sidered a true trend analysis nor can it be considered 
statistically significant. It is, however, better than 
intuition alone. The benefit of this survey is that it 
compares personal computing information from the same organ- 
izations over a two year period. This provides general 
trend information. Unfortunately, the limited geography of 
the sample and absence of scientific process limit the 
effectiveness of its results. [Ref. 167: p. 128] 

APPARENT TRENDS IN PERSONAL COMPUTING 

BASED ON 96 ORGANIZATIONS SURVEYED (1982-1984) 

1982 1984 



Companies with business personal computing 13 68 

In the selection and acquisition of personal 
computers, the MIS department has: 

control over the selection process 2 52 

advisory capacity only 6 13 

no input 3 3 

Formal user training program 0 26 

Formal help desk 0 33 

Company planning for personal computing 0 8 

Local area networking 0 12 

User groups 2 41 

Personal computing library 0 29 

Equipment demonstration facilities 2 38 



Figure 8. Trends in Personal Computing 
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Based on the degree of success experienced by most ICs , 
even those facing great internal resistance, it appears that 
any organization that makes a bonafide effort at establish- 
ing an IC can be successful. Nevertheless, some organiza- 
tions, unaware of how desperately they are in need of an IC, 
are reluctant to establish one. As one author states: 

Many organizations are spending more on user-purchased 
hardware, software and services than they realize. One 
large manufacturing company discovered that end-user pur- 
chases accounted for 40% of the total dollars spent on 
hardv?are, software and services. In some instances these 
dollars were well spent; in others, they were redundant to 
what was already available. The Information Center should 
adopt a strategy that fits smoothly into the way user 
departments are currently operating. Users should not be 
forced to convert to the Information Center service if it 
will impair their productivity or cost them more. 

[Ref . 168: p. 32 ] 

These organizations are becoming aware of the need to con- 
trol information and information technology. One influence 
on this awareness is the Foreign Corrupt Practices Act 
(FCPA) of 1977 which requires managers to implement internal 
controls on corporate assets. Information, data, and com- 
puting resources are being considered assets under the FCPA 
and therefore should be controlled. Kevin Francella shows, 
in a more universal context, the impact of information as an 
asset: 

As the United States suffers the spasms of moving from an 
industrial society to an information society, US business 
is beginning to regard information as a tangible asset. 
Information processing activities account for about 70 
percent of the US employment, and also account for more 
than 46 percent of the Gross National Product, according 
to figures from the National Science Foundation. 

[Ref. 169: p. 15] 



B. APPLICATION OF THE METHODOLOGY 



The SDLC methodology is a viable way to evaluate and 
implement an IC. This thesis has given general guidance as 
to how to apply a slightly modified version of the SDLC as 
proposed by Michael J. Powers, David R. Adams, and Harlan D. 
Mills [Ref. 170]. The major SDLC modifications were those 
that were required to better adapt the SDLC to the IC situa- 
tion. This methodology can be used as extensively or as 
sparingly as the situation warrants. It also has the flexi- 
bility to complement other methodologies and can be used as 
imaginatively as necessary. For the manager who is suddenly 
faced with the task of establishing an IC and who has no 
idea as to how to proceed, this thesis can be of significant 
value. For the manager with experience with the SDLC meth- 
odology, it should even be easier to benefit from this 
thesis . 

There are other methodologies that can be used to estab- 
lish an IC . One method, as proposed by Jean L. Chastain, is 
to not use any methodology at all:* 

If you want to set up an information center and you don't 
have a lot of money to do it, the best plan may be not to 
plan at all. "I'm challenging you to try it even without 
a budget, without proper support," said Jean L. Chastain, 
information center project manager at Economics 
Laboratory, Inc., a manufacturing company based in St. 
Paul, Minn. "It doesn't take a lot of money. A success- 
ful outcome is determined more by attitude than by budg- 
et," she told a recent conference here. [Ref. 171: p. 22] 

It would seem that this only works where the IC is small and 

not comprehensive. Another method that is highly successful 
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is to utilize familiar methodologies. Wetherbe covers this 
topic well: 

Many organizations develop their own formal systems devel- 
opment methodology. Research indicates that these method- 
ologies seem to work as well as the formalized development 
methodologies. The important thing is that a comprehen- 
sive template or checklist must be used to manage the 
process. One criticism of systems development methodolo- 
gies is that they are often so comprehensive and require 
so much attention to details and procedures that they can 
get in the way of progress particularly for short, simple 
projects. Accordingly, the steps and procedures within a 
systems development methodology should only be considered 
as a checklist, and not every step or procedure should 
necessarily be executed for each development project. In 
other words, some discretion should be used in evaluating 
which items on a checklist are appropriate for a particu- 
lar project. [Ref. 172: p. 129] 

An advantage of the systems approach is the attainment 
of synergy. "This means, simply, that when a system is 
functioning as it should, it produces results with a value 
greater than the total value produced by its separate indi- 
vidual parts." [Ref. 173: p. 5] Another advantage of this 
methodology is explained in the following: 

The value of this hierarchical approach lies in a perspec- 
tive that forces problem solvers and managers to deal with 
problems at different levels of abstraction . That is, 
goals and objectives are formulated with increasing levels 
of detail from top to the bottom of the hierarchy. At the 
top of the organization, goals are described functionally, 
in terms of the overall mission. At the bottom level, the 
objectives are clearly operationalized in terms of speci- 
fic actions that must be taken or specific results that 
must occur. [Ref. 174: p. 18] 

As discussed previously, the feasibility study is usual- 
ly a large part of the SDLC. Nevertheless, it is not a 
mandatory requirement. There are several good reasons for 
performing a feasibility study. One is that formal 



justifications for all projects may be required by the 
organization. Another is to help identify organizational 
priorities. A third reason is to help identify objectives 
and develop a standard against which to measure success. On 
the other hand, there are also good arguments against a 
feasibility study. Since the IC can be considered a re- 
search and development effort, it may require little or no 
justification. Another reason may be that the IC is intui- 
tively justifiable or the benefits are so blatantly abundant 
that a feasibility study is, for all practical purposes, a 
waste of resources. A final reason may be because the IC is 
designed solely to solve a management problem regardless of 
the return on investment. Again, the circumstances dictate 
the action to be taken but more often than not, some sort of 
justification is required. 

C. MILITARY AND FEDERAL APPLICATIONS 

Although this thesis has concentrated on ICs in the 
private sector, this does not have to exclude the military 
or federal agencies. The requirement to eliminate fraud 
waste and abuse in the federal government is a good reason 
to implement an IC. An article from Government Computer 
News [Ref. 175: p. 26] lists two military ICs and fifteen 
other federal ICs that have been implemented. This shows 
that the IC concept will work in federal agencies as well as 
the private sector. 
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This does not mean, however, that implementing an IC is 
any easier in the government than it is in the private 
sector. The government, because of its numerous regulations 
and bureaucratic inflexibility, may cause the application of 
controls and excessive justification during the first or 
second stage of technological assimilation. This could 
nullify the benefits to be gained from an IC. Even worse, 
overregulation could cause the IC to fail before it had a 
chance to prove its value. It seems, however, that those 
agencies that have tried to establish ICs have been success- 
ful. Therefore, other federal agencies can learn not only 
from this group of successful implementors, but they can 
also learn from the ICs implemented in the private sector. 
Therefore, this thesis can be of value to the federal 
manager . 

D. EPILOGUE 

There is general agreement that a properly implemented 
IC is a "win-win situation for users and DP (data processing, 
department) alike." [Ref. 176: p. 25] Although managers 
are still asking what an IC can do for their organization, 
these same managers "are beginning to realize that the 
benefits of information access and analytical capability 
outweigh the time taken to handle the mechanics of the 
process." [Ref. 177: p. 33] Appendix A is a combination 
of two lists of IC benefits: one list is from the FTP 



survey [Ref. 178: p. 36] and the other list is from from The 
Crwth Information Center Survey [Ref. 179; p. 17]. These 
lists are intended as examples of reasons for an organiza- 
tion to establish an IC. These two lists should not be 
compared against each other because the sample sizes, the 
questions, and the responses were different for each study. 
The only comparison intended, is to provide the opportunity 
to note benefits that show up on both lists and which can 
therefore be considered to more accurately reflect the more 
important, or at least the most notable, benefits. 

Because benefits of ICs have been identified, it seems 
appropriate to identify the obstacles that were listed by 
the same two previous surveys, the FTP survey [Ref. 180: 
p. 37] and The Crwth Information Center Survey [Ref. 181: 
p. 18]. The list of obstacles may help the developer of an 
IC as much, if not more, than the list of benefits. The 
same comparison criteria applies to obstacles as applied to 
benefits . 

Prioritizing can be a problem for managers. IC priori- 
ties are sometimes difficult to verbalize, let alone rank. 
Therefore, Appendix C [Ref. 182: p. 128] has been provided 
to show the major personal computing problems listed in 
order of importance as ranked by 52 MIS managers attending a 
seminar on IC management. This list can also be used by the 
IC developer as a checklist. 



The future of ICs seems secure for the moment. They 

have achieved momentum and are propagating rather rapidly. 

Some people are saying that ICs are, at best, only temporary 

institutions as stated in the following: 

An information center is not a permanent ins ti tution . . . . An 
IC is a limited, short-term concept that is a stepping- 
stone on the road to what one IC specialist, Bernard 
Flagman, calls "end-user computing .... We won't need the 
information center when natural language processing be- 
comes the front end of computers, and when the so-called 
'expert systems' become business-oriented instead of DP- 
oriented as they are today." [Ref. 183: p. 45] 

This view of the future of ICs ignores the management gap 
that the IC concept fills. Unless there is a drastic re- 
structuring of organizations, most organizations will still 
need some form of centralized control and expertise for end 
user computing. The only lingering question is whether 
ultimately the IC tools will eventually be treated as casu- 
ally as the telephone is today, or whether there will always 
be a need for the IC. It is this author's opinion that the 
IC is more permanent than it is temporary. 



APPENDIX A 



BENEFITS OF INFORI4ATION CENTERS 



FTP SURVEY (1983) 




CRWTH SURVEY (1984) 


Increased End-User Computer 


1 . 


Increased Job 


Understanding, including 




Productivity 


IS Resource Utilization, 
Procedures and Problems 


2 . 


Better Use of Infor- 
mation Resources 


Improved End-User/IS 
Department Relations 


3. 


Improved Computer 
Literacy 


More Effective Utilization 
of IS People Resources 


4. 


Improved DP/End User 
Relations 


Improved End-User 
Productivity 


5. 


Reduction of DP 
Backlog 



5. End-User More Self- 
Sufficient, Independent 

6. Improved Decision-Making 
Support 

7 . Ease of Access to Infor- 
mation 

8. Reduction in Applications 
Backlog 

9. Corporate Management Sees 
IS as More Responsive 

10. Other Benefits 

Overall Cost Reduction 
Better Definition of Business Needs 
Reduction of Outside Timesharing Costs 
Increased Creative Use of Computing 
Better Resource Management 
Developing Training for the Department 
Automation of Considerable Clerical Tasks 
"Flexible" Applications 
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APPENDIX B 



OBSTACLES OF INFORMATION CENTERS 



FTP SURVEY { 1 983) 



CRWTH SURVEY (1984) 



1 . Inadequate IS Resources 
to Support IC 



1 . Shortage of Trainers 
and Product Consultants 



2. Resistance within IS, 
Territorial Conflicts 



2. Lack of End User Aware- 
ness 



3. Software Limitations 



3. System Resource Shortage 




5. Lack of End-User Commit- 
ment to Concept 



6. Lack of Chargeback 



6. End-User Reluctance to 
Train, Do the Work 

7. Lack of Business Reason, Cost- Justification 

8. Defining Criteria for Applications - IC vs. Regular 
Development 

9. Lack of Adequate Vendor Support 

10. Lack of Resources to Train End-Users 

1 1 . Budget Constraints 

12. Management's Attitude 

1 3 . Other : 

Data Security 

Selection of . Initial End-Users and Timeframe 

Restrictions on Choice of Hardware and Software 

Poor Implementation 

Overlay High End-User Expectations 

Poor Follow-Through by IC Staff 

Too Late, Generation Language Already Implemented 

Growth in Utilization 

Lack of Charge-Back Methodology 

Lack of Adequate Standards 
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APPENDIX C 



MAJOR PERSONAL COMPUTING PROBLEMS 

1 . Lack of a company plan for personal computing. 

2 . Lack of user education regarding a companywide and a 
long-term perspective about personal computing. 

3. Unnecessarily high costs to the company due to users 
learning by trial and error about lack of compatibility 
with other micros. 

4. Poor maintainability of user-developed systems. 

5. General lack of communication between the MIS 
department and users. 

6. Overwhelming growth of user requests for assistance 
from the MIS department. 

7. Unnecessarily high costs to the company due to users 
learning by trial and error how to use available 
software packages. 

8. Contamination of corporate data on the company's 
mainframe . 

9. Mismatch of user applications to other possible user 
computing alternatives, such as mainframe packages or 
the traditional approach for systems development. 

10. MIS department has image problem with personal 
computing users. 

11. Lack of equivalent or better (more user-friendly, etc.) 
mainframe software packages to compete successfully 
with microcomputer software packages. 

12. Lack of adequate training on products, computer 
concepts, etc. 

13. Unnecessarily high costs to the company due to users 
"reinventing the wheel" in systems development. 

14. Lack of user knowledge or concern about microcomputer 
data integrity measures such as a file backup. 
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15. Lack of integration of micro/mainframe data exchange 
and control. 

16. Inability of mainframe computing to compete with 
personal computing in terms of cost/benefit in certain 
areas . 

17. Lack of control over user computing resources 
utilization in user departments by the user department 
management. 

18. Lack of adequate support from hardware vendors. 

19. Lack of adequate support from software vendors. 

20. Lack of control over user computing resources 
utilization in user departments by the MIS department. 

21 . Personal computing is further straining MIS department 
relations with users. 

22. Lack of centralized management over corporate data 
resources to support user personal computing. 

23. Lack of appropriate staffing to identify and service 
potential information center customers. 

24. Lack of user concern about personal computing equipment 
security . 

25. Information overloading due to too many vendors and 

products in a given area: micros, software packages, 

local area networks, etc. 

26. Lack of user interest in using personal computers. 

27. Lack of integration in MIS management of personal 
computing and mainframe user computing. 

28. Unnecessarily high costs to the company due to users 
learning by trial and error about lack of compatibility 
with other micros. 

29. Unnecessarily high costs to the company due to users 
learning by trial and error how to negotiate with 
vendors . 

30. Measuring the level of user computing activity. 
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31 . Unnecessarily high costs to the company due to users 
learning by trial and error about lack of compatibility 
with microcomputer peripherals. 

32. Malicious or unauthorized user behavior regarding 
company property. 



NOTE: The above listing represents the concerns of 52 MIS 
managers at a seminar on information center management. The 
list is rank ordered based on the average level of 
importance from most important (1) to least important (32). 
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